The client-go credential plugins can now be passed in the current cluster information via the KUBERNETES_EXEC_INFO environment variable. Learn more about this on client-go credential plugins documentation.
기능 게이트(feature gate)를 통해 크론잡(CronJob) 컨트롤러 v2 활성화 가능
An alternative implementation of CronJob controller is now available as an alpha feature in this release, which has experimental performance improvement by using informers instead of polling. While this will be the default behavior in the future, you can try them in this release through a feature gate.
PID 제한(PID Limits)이 안정 기능(General Availability)으로 전환
PID Limits features are now generally available on both SupportNodePidsLimit (node-to-pod PID isolation) and SupportPodPidsLimit (ability to limit PIDs per pod), after being enabled-by-default in beta stage for a year.
API 우선순위 및 공정성(API Priority and Fairness)이 베타 단계로 전환
IPv4/IPv6 dual-stack has been reimplemented for 1.20 to support dual-stack Services, based on user and community feedback. If your cluster has dual-stack enabled, you can create Services which can use IPv4, IPv6, or both, and you can change this setting for existing Services. Details are available in updated IPv4/IPv6 dual-stack docs, which cover the nuanced array of options.
We expect this implementation to progress from alpha to beta and GA in coming releases, so we’re eager to have you comment about your dual-stack experiences in #k8s-dual-stack or in enhancements #563.
CSI Volume Snapshot moves to GA in the 1.20 release. This feature provides a standard way to trigger volume snapshot operations in Kubernetes and allows Kubernetes users to incorporate snapshot operations in a portable manner on any Kubernetes environment regardless of supporting underlying storage providers.
Additionally, these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise grade, storage administration features for Kubernetes: including application or cluster level backup solutions.
Note that snapshot support will require Kubernetes distributors to bundle the Snapshot controller, Snapshot CRDs, and validation webhook. In addition, a CSI driver supporting the snapshot functionality must also be deployed on the cluster.
비재귀적 볼륨 소유(Non-recursive Volume Ownership (FSGroup))가 베타 단계로 전환
By default, the fsgroup setting, if specified, recursively updates permissions for every file in a volume on every mount. This can make mount, and pod startup, very slow if the volume has many files.
This setting enables a pod to specify a PodFSGroupChangePolicy that indicates that volume ownership and permissions will be changed only when permission and ownership of the root directory does not match with expected permissions on the volume.
FSGroup를 위한 CSIDriver 정책이 베타 단계로 전환
The FSGroup's CSIDriver Policy is now beta in 1.20. This allows CSIDrivers to explicitly indicate if they want Kubernetes to manage permissions and ownership for their volumes via fsgroup.
CSI 드라이버의 보안성 향상(알파)
In 1.20, we introduce a new alpha feature CSIServiceAccountToken. This feature allows CSI drivers to impersonate the pods that they mount the volumes for. This improves the security posture in the mounting process where the volumes are ACL’ed on the pods’ service account without handing out unnecessary permissions to the CSI drivers’ service account. This feature is especially important for secret-handling CSI drivers, such as the secrets-store-csi-driver. Since these tokens can be rotated and short-lived, this feature also provides a knob for CSI drivers to receive NodePublishVolume RPC calls periodically with the new token. This knob is also useful when volumes are short-lived, e.g. certificates.
그레이스풀 노드 종료(Graceful Node Shutdown) 기능 소개(알파)
The GracefulNodeShutdown feature is now in Alpha. This allows kubelet to be aware of node system shutdowns, enabling graceful termination of pods during a system shutdown. This feature can be enabled through feature gate.
On-demand metrics calculation is now available through /metrics/resources. When enabled, the endpoint will report the requested resources and the desired limits of all running pods.
RootCAConfigMap 소개
RootCAConfigMap graduates to Beta, seperating from BoundServiceAccountTokenVolume. The kube-root-ca.crt ConfigMap is now available to every namespace, by default. It contains the Certificate Authority bundle for verify kube-apiserver connections.
kubectl debug 이 베타 단계로 전환
kubectl alpha debug graduates from alpha to beta in 1.20, becoming kubectl debug.
kubectl debug provides support for common debugging workflows directly from kubectl. Troubleshooting scenarios supported in this release of kubectl include:
Troubleshoot workloads that crash on startup by creating a copy of the pod that uses a different container image or command.
Troubleshoot distroless containers by adding a new container with debugging tools, either in a new copy of the pod or using an ephemeral container. (Ephemeral containers are an alpha feature that are not enabled by default.)
Troubleshoot on a node by creating a container running in the host namespaces and with access to the host’s filesystem.
Note that as a new builtin command, kubectl debug takes priority over any kubectl plugin named “debug”. You will need to rename the affected plugin.
Invocations using kubectl alpha debug are now deprecated and will be removed in a subsequent release. Update your scripts to use kubectl debug instead of kubectl alpha debug!
For more information about kubectl debug, see Debugging Running Pods on the Kubernetes website, kubectl help debug, or reach out to SIG CLI by visiting #sig-cli or commenting on enhancement #1441.
kubeadm에서 사용 중단된 플래그 삭제
kubeadm applies a number of deprecations and removals of deprecated features in this release. More details are available in the Urgent Upgrade Notes and Kind / Deprecation sections.
파드의 호스트네임을 FQDN으로 사용하는 것이 베타 단계로 전환
Previously introduced in 1.19 behind a feature gate, SetHostnameAsFQDN is now enabled by default. More details on this behavior is available in documentation for DNS for Services and Pods
TokenRequest / TokenRequestProjection 이 안정 기능으로 전환
Service account tokens bound to pod is now a stable feature. The feature gates will be removed in 1.21 release. For more information, refer to notes below on the changelogs.
런타임클래스(RuntimeClass)가 안정 기능으로 전환
The node.k8s.io API groups are promoted from v1beta1 to v1. v1beta1 is now deprecated and will be removed in a future release, please start using v1. (#95718, @SergeyKanzhelev) [SIG Apps, Auth, Node, Scheduling and Testing]
클라우드 컨트롤러 관리자(Cloud Controller Manager)가 이제 각 클라우드 공급자를 통해서만 제공
Kubernetes will no longer ship an instance of the Cloud Controller Manager binary. Each Cloud Provider is expected to ship their own instance of this binary. Details for a Cloud Provider to create an instance of such a binary can be found under here. Anyone with questions on building a Cloud Controller Manager should reach out to SIG Cloud Provider. Questions about the Cloud Controller Manager on a Managed Kubernetes solution should go to the relevant Cloud Provider. Questions about the Cloud Controller Manager on a non managed solution can be brought up with SIG Cloud Provider.
알려진 이슈
kubelet의 요약(Summary) API는 가속기(accelerator) 메트릭을 가지고 있지 않음
Currently, cadvisor_stats_provider provides AcceleratorStats but cri_stats_provider does not. As a result, when using cri_stats_provider, kubelet's Summary API does not have accelerator metrics. There is an open work in progress to fix this.
긴급 업그레이드 노트
(주의. 업그레이드 전에 반드시 읽어야 함)
A bug was fixed in kubelet where exec probe timeouts were not respected. This may result in unexpected behavior since the default timeout (if not specified) is 1s which may be too small for some exec probes. Ensure that pods relying on this behavior are updated to correctly handle probe timeouts. See configure probe section of the documentation for more details.
This change in behavior may be unexpected for some clusters and can be disabled by turning off the ExecProbeTimeout feature gate. This gate will be locked and removed in future releases so that exec probe timeouts are always respected. (#94115, @andrewsykim) [SIG Node and Testing]
RuntimeClass feature graduates to General Availability. Promote node.k8s.io API groups from v1beta1 to v1. v1beta1 is now deprecated and will be removed in a future release, please start using v1. (#95718, @SergeyKanzhelev) [SIG Apps, Auth, Node, Scheduling and Testing]
API priority and fairness graduated to beta. 1.19 servers with APF turned on should not be run in a multi-server cluster with 1.20+ servers. (#96527, @adtac) [SIG API Machinery and Testing]
For CSI drivers, kubelet no longer creates the target_path for NodePublishVolume in accordance with the CSI spec. Kubelet also no longer checks if staging and target paths are mounts or corrupted. CSI drivers need to be idempotent and do any necessary mount verification. (#88759, @andyzhangx) [SIG Storage]
The label applied to control-plane nodes "node-role.kubernetes.io/master" is now deprecated and will be removed in a future release after a GA deprecation period.
Introduce a new label "node-role.kubernetes.io/control-plane" that will be applied in parallel to "node-role.kubernetes.io/master" until the removal of the "node-role.kubernetes.io/master" label.
Make "kubeadm upgrade apply" add the "node-role.kubernetes.io/control-plane" label on existing nodes that only have the "node-role.kubernetes.io/master" label during upgrade.
Please adapt your tooling built on top of kubeadm to use the "node-role.kubernetes.io/control-plane" label.
The taint applied to control-plane nodes "node-role.kubernetes.io/master:NoSchedule" is now deprecated and will be removed in a future release after a GA deprecation period.
Apply toleration for a new, future taint "node-role.kubernetes.io/control-plane:NoSchedule" to the kubeadm CoreDNS / kube-dns managed manifests. Note that this taint is not yet applied to kubeadm control-plane nodes.
Please adapt your workloads to tolerate the same future taint preemptively.
Kubeadm: improve the validation of serviceSubnet and podSubnet.
ServiceSubnet has to be limited in size, due to implementation details, and the mask can not allocate more than 20 bits.
PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible.
kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly.
Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. (#95723, @aojea) [SIG Cluster Lifecycle]
The deprecated flag --experimental-kustomize is now removed from kubeadm commands. Use --experimental-patches instead, which was introduced in 1.19. Migration information available in --help description for --experimental-patches. (#94871, @neolit123)
Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 (#95505, @wawa0210) [SIG Node and Windows]
The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags --address and --insecure-bind-address have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags --port and --insecure-port may only be set to 0 and will be removed in v1.24. (#95856, @knight42, [SIG API Machinery, Node, Testing])
Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API.
It changes the dual-stack API wrt Service from a single ipFamily field to 3
fields: ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack),
ipFamilies (a list of families assigned), and clusterIPs (inclusive of
clusterIP). Most users do not need to set anything at all, defaulting will
handle it for them. Services are single-stack unless the user asks for
dual-stack. This is all gated by the "IPv6DualStack" feature gate. (#91824, @khenidak) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing]
TokenRequest and TokenRequestProjection are now GA features. The following flags are required by the API server:
--service-account-issuer, should be set to a URL identifying the API server that will be stable over the cluster lifetime.
--service-account-key-file, set to one or more files containing one or more public keys used to verify tokens.
--service-account-signing-key-file, set to a file containing a private key to use to sign service account tokens. Can be the same file given to kube-controller-manager with --service-account-private-key-file. (#95896, @zshihang) [SIG API Machinery, Auth, Cluster Lifecycle]
kubeadm: make the command "kubeadm alpha kubeconfig user" accept a "--config" flag and remove the following flags:
apiserver-advertise-address / apiserver-bind-port: use either localAPIEndpoint from InitConfiguration or controlPlaneEndpoint from ClusterConfiguration.
cluster-name: use clusterName from ClusterConfiguration
cert-dir: use certificatesDir from ClusterConfiguration (#94879, @knight42) [SIG Cluster Lifecycle]
Resolves non-deterministic behavior of the garbage collection controller when ownerReferences with incorrect data are encountered. Events with a reason of OwnerRefInvalidNamespace are recorded when namespace mismatches between child and owner objects are detected. The kubectl-check-ownerreferences tool can be run prior to upgrading to locate existing objects with invalid ownerReferences.
A namespaced object with an ownerReference referencing a uid of a namespaced kind which does not exist in the same namespace is now consistently treated as though that owner does not exist, and the child object is deleted.
A cluster-scoped object with an ownerReference referencing a uid of a namespaced kind is now consistently treated as though that owner is not resolvable, and the child object is ignored by the garbage collector. (#92743, @liggitt) [SIG API Machinery, Apps and Testing]
종류(Kind)별 변경 사항
사용 중단
Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]
Kubeadm: deprecate self-hosting support. The experimental command "kubeadm alpha self-hosting" is now deprecated and will be removed in a future release. (#95125, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: graduate the "kubeadm alpha certs" command to a parent command "kubeadm certs". The command "kubeadm alpha certs" is deprecated and will be removed in a future release. Please migrate. (#94938, @yagonobre) [SIG Cluster Lifecycle]
Kubeadm: remove the deprecated "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. This change also removes the parent command "kubeadm alpha kubelet" as there are no more sub-commands under it for the time being. (#94668, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: remove the deprecated --kubelet-config flag for the command "kubeadm upgrade node" (#94869, @neolit123) [SIG Cluster Lifecycle]
Scheduler alpha metrics binding_duration_seconds and scheduling_algorithm_preemption_evaluation_seconds are deprecated, Both of those metrics are now covered as part of framework_extension_point_duration_seconds, the former as a PostFilter the latter and a Bind plugin. The plan is to remove both in 1.21 (#95001, @arghya88) [SIG Instrumentation and Scheduling]
Support 'controlplane' as a valid EgressSelection type in the EgressSelectorConfiguration API. 'Master' is deprecated and will be removed in v1.22. (#95235, @andrewsykim) [SIG API Machinery]
The v1alpha1 PodPreset API and admission plugin has been removed with no built-in replacement. Admission webhooks can be used to modify pods on creation. (#94090, @deads2k) [SIG API Machinery, Apps, CLI, Cloud Provider, Scalability and Testing]
kubeadm's kube-apiserver Pod manifest now includes the following flags by default "--service-account-key-file", "--service-account-signing-key-file", "--service-account-issuer". (#93258, @zshihang) [SIG API Machinery, Auth, Cluster Lifecycle, Storage and Testing]
A new nofuzz go build tag now disables gofuzz support. Release binaries enable this. (#92491, @BenTheElder) [SIG API Machinery]
Add WindowsContainerResources and Annotations to CRI-API UpdateContainerResourcesRequest (#95741, @katiewasnothere) [SIG Node]
Add a serving and terminating condition to the EndpointSlice API.
serving tracks the readiness of endpoints regardless of their terminating state. This is distinct from ready since ready is only true when pods are not terminating.
terminating is true when an endpoint is terminating. For pods this is any endpoint with a deletion timestamp. (#92968, @andrewsykim) [SIG Apps and Network]
Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API.
It changes the dual-stack API wrt Service from a single ipFamily field to 3
fields: ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack),
ipFamilies (a list of families assigned), and clusterIPs (inclusive of
clusterIP). Most users do not need to set anything at all, defaulting will
handle it for them. Services are single-stack unless the user asks for
dual-stack. This is all gated by the "IPv6DualStack" feature gate. (#91824, @khenidak) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing]
Add support for hugepages to downward API (#86102, @derekwaynecarr) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing]
Adds kubelet alpha feature, GracefulNodeShutdown which makes kubelet aware of node system shutdowns and result in graceful termination of pods during a system shutdown. (#96129, @bobbypage) [SIG Node]
AppProtocol is now GA for Endpoints and Services. The ServiceAppProtocol feature gate will be deprecated in 1.21. (#96327, @robscott) [SIG Apps and Network]
Automatic allocation of NodePorts for services with type LoadBalancer can now be disabled by setting the (new) parameter
Service.spec.allocateLoadBalancerNodePorts=false. The default is to allocate NodePorts for services with type LoadBalancer which is the existing behavior. (#92744, @uablrek) [SIG Apps and Network]
Certain fields on Service objects will be automatically cleared when changing the service's type to a mode that does not need those fields. For example, changing from type=LoadBalancer to type=ClusterIP will clear the NodePort assignments, rather than forcing the user to clear them. (#95196, @thockin) [SIG API Machinery, Apps, Network and Testing]
Document that ServiceTopology feature is required to use service.spec.topologyKeys. (#96528, @andrewsykim) [SIG Apps]
EndpointSlice has a new NodeName field guarded by the EndpointSliceNodeName feature gate.
EndpointSlice topology field will be deprecated in an upcoming release.
EndpointSlice "IP" address type is formally removed after being deprecated in Kubernetes 1.17.
The discovery.k8s.io/v1alpha1 API is deprecated and will be removed in Kubernetes 1.21. (#96440, @robscott) [SIG API Machinery, Apps and Network]
External facing API podresources is now available under k8s.io/kubelet/pkg/apis/ (#92632, @RenaudWasTaken) [SIG Node and Testing]
Fewer candidates are enumerated for preemption to improve performance in large clusters. (#94814, @adtac)
Fix conversions for custom metrics. (#94481, @wojtek-t) [SIG API Machinery and Instrumentation]
GPU metrics provided by kubelet are now disabled by default. (#95184, @RenaudWasTaken)
If BoundServiceAccountTokenVolume is enabled, cluster admins can use metric serviceaccount_stale_tokens_total to monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off extended tokens by starting kube-apiserver with flag --service-account-extend-token-expiration=false (#96273, @zshihang) [SIG API Machinery and Auth]
Introduce alpha support for exec-based container registry credential provider plugins in the kubelet. (#94196, @andrewsykim) [SIG Node and Release]
Introduces a metric source for HPAs which allows scaling based on container resource usage. (#90691, @arjunrn) [SIG API Machinery, Apps, Autoscaling and CLI]
Kube-apiserver now deletes expired kube-apiserver Lease objects:
The feature is under feature gate APIServerIdentity.
A flag is added to kube-apiserver: identity-lease-garbage-collection-check-period-seconds (#95895, @roycaihw) [SIG API Machinery, Apps, Auth and Testing]
Kube-controller-manager: volume plugins can be restricted from contacting local and loopback addresses by setting --volume-host-allow-local-loopback=false, or from contacting specific CIDR ranges by setting --volume-host-cidr-denylist (for example, --volume-host-cidr-denylist=127.0.0.1/28,feed::/16) (#91785, @mattcary) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing]
Migrate scheduler, controller-manager and cloud-controller-manager to use LeaseLock (#94603, @wojtek-t) [SIG API Machinery, Apps, Cloud Provider and Scheduling]
Modify DNS-1123 error messages to indicate that RFC 1123 is not followed exactly (#94182, @mattfenwick) [SIG API Machinery, Apps, Auth, Network and Node]
Move configurable fsgroup change policy for pods to beta (#96376, @gnufied) [SIG Apps and Storage]
New flag is introduced, i.e. --topology-manager-scope=container|pod.
The default value is the "container" scope. (#92967, @cezaryzukowski) [SIG Instrumentation, Node and Testing]
New parameter defaultingType for PodTopologySpread plugin allows to use k8s defined or user provided default constraints (#95048, @alculquicondor) [SIG Scheduling]
NodeAffinity plugin can be configured with AddedAffinity. (#96202, @alculquicondor) [SIG Node, Scheduling and Testing]
Promote RuntimeClass feature to GA.
Promote node.k8s.io API groups from v1beta1 to v1. (#95718, @SergeyKanzhelev) [SIG Apps, Auth, Node, Scheduling and Testing]
Reminder: The labels "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" are deprecated in favor of "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" respectively. All users of the "failure-domain.beta..." labels should switch to the "topology..." equivalents. (#96033, @thockin) [SIG API Machinery, Apps, CLI, Cloud Provider, Network, Node, Scheduling, Storage and Testing]
Server Side Apply now treats LabelSelector fields as atomic (meaning the entire selector is managed by a single writer and updated together), since they contain interrelated and inseparable fields that do not merge in intuitive ways. (#93901, @jpbetz) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Storage and Testing]
Services will now have a clusterIPs field to go with clusterIP. clusterIPs[0] is a synonym for clusterIP and will be syncronized on create and update operations. (#95894, @thockin) [SIG Network]
The ServiceAccountIssuerDiscovery feature gate is now Beta and enabled by default. (#91921, @mtaufen) [SIG Auth]
The status of v1beta1 CRDs without "preserveUnknownFields:false" now shows a violation, "spec.preserveUnknownFields: Invalid value: true: must be false". (#93078, @vareti)
The usage of mixed protocol values in the same LoadBalancer Service is possible if the new feature gate MixedProtocolLBService is enabled. The feature gate is disabled by default. The user has to enable it for the API Server. (#94028, @janosi) [SIG API Machinery and Apps]
This PR will introduce a feature gate CSIServiceAccountToken with two additional fields in CSIDriverSpec. (#93130, @zshihang) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing]
Users can try the cronjob controller v2 using the feature gate. This will be the default controller in future releases. (#93370, @alaypatel07) [SIG API Machinery, Apps, Auth and Testing]
VolumeSnapshotDataSource moves to GA in 1.20 release (#95282, @xing-yang) [SIG Apps]
WinOverlay feature graduated to beta (#94807, @ksubrmnn) [SIG Windows]
A new metric apiserver_request_filter_duration_seconds has been introduced that
measures request filter latency in seconds. (#95207, @tkashem) [SIG API Machinery and Instrumentation]
A new set of alpha metrics are reported by the Kubernetes scheduler under the /metrics/resources endpoint that allow administrators to easily see the resource consumption (requests and limits for all resources on the pods) and compare it to actual pod usage or node capacity. (#94866, @smarterclayton) [SIG API Machinery, Instrumentation, Node and Scheduling]
Add --experimental-logging-sanitization flag enabling runtime protection from leaking sensitive data in logs (#96370, @serathius) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
Add a StorageVersionAPI feature gate that makes API server update storageversions before serving certain write requests.
This feature allows the storage migrator to manage storage migration for built-in resources.
Enabling internal.apiserver.k8s.io/v1alpha1 API and APIServerIdentity feature gate are required to use this feature. (#93873, @roycaihw) [SIG API Machinery, Auth and Testing]
Add a metric for time taken to perform recursive permission change (#95866, @JornShen) [SIG Instrumentation and Storage]
Add a new vSphere metric: cloudprovider_vsphere_vcenter_versions. It's content show vCenter hostnames with the associated server version. (#94526, @Danil-Grigorev) [SIG Cloud Provider and Instrumentation]
Add a new flag to set priority for the kubelet on Windows nodes so that workloads cannot overwhelm the node there by disrupting kubelet process. (#96051, @ravisantoshgudimetla) [SIG Node and Windows]
Add feature to size memory backed volumes (#94444, @derekwaynecarr) [SIG Storage and Testing]
Add foreground cascading deletion to kubectl with the new kubectl delete foreground|background|orphan option. (#93384, @zhouya0)
Add metrics for azure service operations (route and loadbalancer). (#94124, @nilo19) [SIG Cloud Provider and Instrumentation]
Add network rule support in Azure account creation. (#94239, @andyzhangx)
Add node_authorizer_actions_duration_seconds metric that can be used to estimate load to node authorizer. (#92466, @mborsz) [SIG API Machinery, Auth and Instrumentation]
Add pod_ based CPU and memory metrics to Kubelet's /metrics/resource endpoint (#95839, @egernst) [SIG Instrumentation, Node and Testing]
Added get-users and delete-user to the kubectl config subcommand (#89840, @eddiezane) [SIG CLI]
Added counter metric "apiserver_request_self" to count API server self-requests with labels for verb, resource, and subresource. (#94288, @LogicalShark) [SIG API Machinery, Auth, Instrumentation and Scheduling]
Added new k8s.io/component-helpers repository providing shared helper code for (core) components. (#92507, @ingvagabund) [SIG Apps, Node, Release and Scheduling]
Adds create ingress command to kubectl (#78153, @amimof) [SIG CLI and Network]
Adds a headless service on node-local-cache addon. (#88412, @stafot) [SIG Cloud Provider and Network]
Allow cross compilation of kubernetes on different platforms. (#94403, @bnrjee) [SIG Release]
Azure: Support multiple services sharing one IP address (#94991, @nilo19) [SIG Cloud Provider]
CRDs: For structural schemas, non-nullable null map fields will now be dropped and defaulted if a default is available. null items in list will continue being preserved, and fail validation if not nullable. (#95423, @apelisse) [SIG API Machinery]
Client-go credential plugins can now be passed in the current cluster information via the KUBERNETES_EXEC_INFO environment variable. (#95489, @ankeesler) [SIG API Machinery and Auth]
Command to start network proxy changes from 'KUBE_ENABLE_EGRESS_VIA_KONNECTIVITY_SERVICE ./cluster/kube-up.sh' to 'KUBE_ENABLE_KONNECTIVITY_SERVICE=true ./hack/kube-up.sh' (#92669, @Jefftree) [SIG Cloud Provider]
Configure AWS LoadBalancer health check protocol via service annotations. (#94546, @kishorj)
DefaultPodTopologySpread graduated to Beta. The feature gate is enabled by default. (#95631, @alculquicondor) [SIG Scheduling and Testing]
E2e test for PodFsGroupChangePolicy (#96247, @saikat-royc) [SIG Storage and Testing]
Ephemeral containers now apply the same API defaults as initContainers and containers (#94896, @wawa0210) [SIG Apps and CLI]
Gradudate the Pod Resources API to G.A
Introduces the pod_resources_endpoint_requests_total metric which tracks the total number of requests to the pod resources API (#92165, @RenaudWasTaken) [SIG Instrumentation, Node and Testing]
In dual-stack bare-metal clusters, you can now pass dual-stack IPs to kubelet --node-ip.
eg: kubelet --node-ip 10.1.0.5,fd01::0005. This is not yet supported for non-bare-metal
clusters.
In dual-stack clusters where nodes have dual-stack addresses, hostNetwork pods
will now get dual-stack PodIPs. (#95239, @danwinship) [SIG Network and Node]
Introduce api-extensions category which will return: mutating admission configs, validating admission configs, CRDs and APIServices when used in kubectl get, for example. (#95603, @soltysh) [SIG API Machinery]
Introduces a new GCE specific cluster creation variable KUBE_PROXY_DISABLE. When set to true, this will skip over the creation of kube-proxy (whether the daemonset or static pod). This can be used to control the lifecycle of kube-proxy separately from the lifecycle of the nodes. (#91977, @varunmar) [SIG Cloud Provider]
Kube-apiserver now maintains a Lease object to identify itself:
The feature is under feature gate APIServerIdentity.
Two flags are added to kube-apiserver: identity-lease-duration-seconds, identity-lease-renew-interval-seconds (#95533, @roycaihw) [SIG API Machinery]
Kube-apiserver: The timeout used when making health check calls to etcd can now be configured with --etcd-healthcheck-timeout. The default timeout is 2 seconds, matching the previous behavior. (#93244, @Sh4d1) [SIG API Machinery]
Kube-apiserver: added support for compressing rotated audit log files with --audit-log-compress (#94066, @lojies) [SIG API Machinery and Auth]
Kubeadm now prints warnings instead of throwing errors if the current system time is outside of the NotBefore and NotAfter bounds of a loaded certificate. (#94504, @neolit123)
Kubeadm: Add a preflight check that the control-plane node has at least 1700MB of RAM (#93275, @xlgao-zju) [SIG Cluster Lifecycle]
Kubeadm: add the "--cluster-name" flag to the "kubeadm alpha kubeconfig user" to allow configuring the cluster name in the generated kubeconfig file (#93992, @prabhu43) [SIG Cluster Lifecycle]
Kubeadm: add the "--kubeconfig" flag to the "kubeadm init phase upload-certs" command to allow users to pass a custom location for a kubeconfig file. (#94765, @zhanw15) [SIG Cluster Lifecycle]
Kubeadm: make etcd pod request 100m CPU, 100Mi memory and 100Mi ephemeral_storage by default (#94479, @knight42) [SIG Cluster Lifecycle]
Kubeadm: make the command "kubeadm alpha kubeconfig user" accept a "--config" flag and remove the following flags:
apiserver-advertise-address / apiserver-bind-port: use either localAPIEndpoint from InitConfiguration or controlPlaneEndpoint from ClusterConfiguration.
cluster-name: use clusterName from ClusterConfiguration
cert-dir: use certificatesDir from ClusterConfiguration (#94879, @knight42) [SIG Cluster Lifecycle]
Kubectl create now supports creating ingress objects. (#94327, @rikatz) [SIG CLI and Network]
Kubectl rollout history sts/sts-name --revision=some-revision will start showing the detailed view of the sts on that specified revision (#86506, @dineshba) [SIG CLI]
Kubectl: Previously users cannot provide arguments to a external diff tool via KUBECTL_EXTERNAL_DIFF env. This release now allow users to specify args to KUBECTL_EXTERNAL_DIFF env. (#95292, @dougsland) [SIG CLI]
Kubemark now supports both real and hollow nodes in a single cluster. (#93201, @ellistarn) [SIG Scalability]
Kubernetes E2E test image manifest lists now contain Windows images. (#77398, @claudiubelu) [SIG Testing and Windows]
build: Use go-runner:buster-v2.0.1 (built using go1.15.1)
bazel: Replace --features with Starlark build settings flag
hack/lib/util.sh: some bash cleanups
switched one spot to use kube::logging
make kube::util::find-binary return an error when it doesn't find
anything so that hack scripts fail fast instead of with '' binary not
found errors.
this required deleting some genfeddoc stuff. the binary no longer
exists in k/k repo since we removed federation/, and I don't see it
in https://github.com/kubernetes-sigs/kubefed/ either. I'm assuming
that it's gone for good now.
bazel: output go_binary rule directly from go_binary_conditional_pure
From: @mikedanese:
Instead of aliasing. Aliases are annoying in a number of ways. This is
specifically bugging me now because they make the action graph harder to
analyze programmatically. By using aliases here, we would need to handle
potentially aliased go_binary targets and dereference to the effective
target.
The comment references an issue with pure = select(...) which appears
to be resolved considering this now builds.
make kube::util::find-binary not dependent on bazel-out/ structure
Implement an aspect that outputs go_build_mode metadata for go binaries,
and use that during binary selection. (#94449, @justaugustus) [SIG Architecture, CLI, Cluster Lifecycle, Node, Release and Testing]
New default scheduling plugins order reduces scheduling and preemption latency when taints and node affinity are used (#95539, @soulxu) [SIG Scheduling]
Only update Azure data disks when attach/detach (#94265, @andyzhangx) [SIG Cloud Provider]
Promote SupportNodePidsLimit to GA to provide node-to-pod PID isolation.
Promote SupportPodPidsLimit to GA to provide ability to limit PIDs per pod. (#94140, @derekwaynecarr)
SCTP support in API objects (Pod, Service, NetworkPolicy) is now GA.
Note that this has no effect on whether SCTP is enabled on nodes at the kernel level,
and note that some cloud platforms and network plugins do not support SCTP traffic. (#95566, @danwinship) [SIG Apps and Network]
Scheduler now ignores Pod update events if the resourceVersion of old and new Pods are identical. (#96071, @Huang-Wei) [SIG Scheduling]
Scheduling Framework: expose Run[Pre]ScorePlugins functions to PreemptionHandle which can be used in PostFilter extention point. (#93534, @everpeace) [SIG Scheduling and Testing]
SelectorSpreadPriority maps to PodTopologySpread plugin when DefaultPodTopologySpread feature is enabled (#95448, @alculquicondor) [SIG Scheduling]
Send GCE node startup scripts logs to console and journal. (#95311, @karan)
SetHostnameAsFQDN has been graduated to Beta and therefore it is enabled by default. (#95267, @javidiaz) [SIG Node]
Support [service.beta.kubernetes.io/azure-pip-ip-tags] annotations to allow customers to specify ip-tags to influence public-ip creation in Azure [Tag1=Value1, Tag2=Value2, etc.] (#94114, @MarcPow) [SIG Cloud Provider]
Support custom tags for cloud provider managed resources (#96450, @nilo19) [SIG Cloud Provider]
Support customize load balancer health probe protocol and request path (#96338, @nilo19) [SIG Cloud Provider]
Support for Windows container images (OS Versions: 1809, 1903, 1909, 2004) was added the pause:3.4 image. (#91452, @claudiubelu) [SIG Node, Release and Windows]
Support multiple standard load balancers in one cluster (#96111, @nilo19) [SIG Cloud Provider]
The beta RootCAConfigMap feature gate is enabled by default and causes kube-controller-manager to publish a "kube-root-ca.crt" ConfigMap to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver. (#96197, @zshihang) [SIG API Machinery, Apps, Auth and Testing]
The kubelet_runtime_operations_duration_seconds metric buckets were set to 0.005 0.0125 0.03125 0.078125 0.1953125 0.48828125 1.220703125 3.0517578125 7.62939453125 19.073486328125 47.6837158203125 119.20928955078125 298.0232238769531 and 745.0580596923828 seconds (#96054, @alvaroaleman) [SIG Instrumentation and Node]
There is a new pv_collector_total_pv_count metric that counts persistent volumes by the volume plugin name and volume mode. (#95719, @tsmetana) [SIG Apps, Instrumentation, Storage and Testing]
Volume snapshot e2e test to validate PVC and VolumeSnapshotContent finalizer (#95863, @RaunakShah) [SIG Cloud Provider, Storage and Testing]
Warns user when executing kubectl apply/diff to resource currently being deleted. (#95544, @SaiHarshaK) [SIG CLI]
kubectl alpha debug has graduated to beta and is now kubectl debug. (#96138, @verb) [SIG CLI and Testing]
kubectl debug gains support for changing container images when copying a pod for debugging, similar to how kubectl set image works. See kubectl help debug for more information. (#96058, @verb) [SIG CLI]
문서
Fake dynamic client: document that List does not preserve TypeMeta in UnstructuredList (#95117, @andrewsykim) [SIG API Machinery]
Kubelet: remove alpha warnings for CNI flags. (#94508, @andrewsykim) [SIG Network and Node]
Updates docs and guidance on cloud provider InstancesV2 and Zones interface for external cloud providers:
removes experimental warning for InstancesV2
document that implementation of InstancesV2 will disable calls to Zones
deprecate Zones in favor of InstancesV2 (#96397, @andrewsykim) [SIG Cloud Provider]
실패 테스트
Resolves an issue running Ingress conformance tests on clusters which use finalizers on Ingress objects to manage releasing load balancer resources (#96742, @spencerhance) [SIG Network and Testing]
The Conformance test "validates that there is no conflict between pods with same hostPort but different hostIP and protocol" now validates the connectivity to each hostPort, in addition to the functionality. (#96627, @aojea) [SIG Scheduling and Testing]
버그 또는 회귀(regression)
Add kubectl wait --ignore-not-found flag (#90969, @zhouya0) [SIG CLI]
Added support to kube-proxy for externalTrafficPolicy=Local setting via Direct Server Return (DSR) load balancers on Windows. (#93166, @elweb9858) [SIG Network]
Alter wording to describe pods using a pvc (#95635, @RaunakShah) [SIG CLI]
An issues preventing volume expand controller to annotate the PVC with volume.kubernetes.io/storage-resizer when the PVC StorageClass is already updated to the out-of-tree provisioner is now fixed. (#94489, @ialidzhikov) [SIG API Machinery, Apps and Storage]
Azure ARM client: don't segfault on empty response and http error (#94078, @bpineau) [SIG Cloud Provider]
Azure armclient backoff step defaults to 1 (no retry). (#94180, @feiskyer)
Azure: fix a bug that kube-controller-manager would panic if wrong Azure VMSS name is configured (#94306, @knight42) [SIG Cloud Provider]
Both apiserver_request_duration_seconds metrics and RequestReceivedTimestamp fields of an audit event now take into account the time a request spends in the apiserver request filters. (#94903, @tkashem)
Build/lib/release: Explicitly use '--platform' in building server images
When we switched to go-runner for building the apiserver,
controller-manager, and scheduler server components, we no longer
reference the individual architectures in the image names, specifically
in the 'FROM' directive of the server image Dockerfiles.
As a result, server images for non-amd64 images copy in the go-runner
amd64 binary instead of the go-runner that matches that architecture.
This commit explicitly sets the '--platform=linux/${arch}' to ensure
we're pulling the correct go-runner arch from the manifest list.
Before:
FROM ${base_image}
After:
FROM --platform=linux/${arch} ${base_image} (#94552, @justaugustus) [SIG Release]
Bump node-problem-detector version to v0.8.5 to fix OOM detection in with Linux kernels 5.1+ (#96716, @tosi3k) [SIG Cloud Provider, Scalability and Testing]
CSIDriver object can be deployed during volume attachment. (#93710, @Jiawei0227) [SIG Apps, Node, Storage and Testing]
Ceph RBD volume expansion now works even when ceph.conf was not provided. (#92027, @juliantaylor)
Change plugin name in fsgroupapplymetrics of csi and flexvolume to distinguish different driver (#95892, @JornShen) [SIG Instrumentation, Storage and Testing]
Change the calculation of pod UIDs so that static pods get a unique value - will cause all containers to be killed and recreated after in-place upgrade. (#87461, @bboreham) [SIG Node]
Change the mount way from systemd to normal mount except ceph and glusterfs intree-volume. (#94916, @smileusd) [SIG Apps, Cloud Provider, Network, Node, Storage and Testing]
Changes to timeout parameter handling in 1.20.0-beta.2 have been reverted to avoid breaking backwards compatibility with existing clients. (#96727, @liggitt) [SIG API Machinery and Testing]
Clear UDP conntrack entry on endpoint changes when using nodeport (#71573, @JacobTanenbaum) [SIG Network]
Disable watchcache for events (#96052, @wojtek-t) [SIG API Machinery]
Disabled LocalStorageCapacityIsolation feature gate is honored during scheduling. (#96092, @Huang-Wei) [SIG Scheduling]
Do not fail sorting empty elements. (#94666, @soltysh) [SIG CLI]
Dual-stack: make nodeipam compatible with existing single-stack clusters when dual-stack feature gate become enabled by default (#90439, @SataQiu) [SIG API Machinery]
Duplicate owner reference entries in create/update/patch requests now get deduplicated by the API server. The client sending the request now receives a warning header in the API response. Clients should stop sending requests with duplicate owner references. The API server may reject such requests as early as 1.24. (#96185, @roycaihw) [SIG API Machinery and Testing]
Endpoint slice controller now mirrors parent's service label to its corresponding endpoint slices. (#94443, @aojea)
Ensure getPrimaryInterfaceID not panic when network interfaces for Azure VMSS are null (#94355, @feiskyer) [SIG Cloud Provider]
Exposes and sets a default timeout for the SubjectAccessReview client for DelegatingAuthorizationOptions (#95725, @p0lyn0mial) [SIG API Machinery and Cloud Provider]
Exposes and sets a default timeout for the TokenReview client for DelegatingAuthenticationOptions (#96217, @p0lyn0mial) [SIG API Machinery and Cloud Provider]
Fix CVE-2020-8555 for Quobyte client connections. (#95206, @misterikkit) [SIG Storage]
Fix IP fragmentation of UDP and TCP packets not supported issues on LoadBalancer rules (#96464, @nilo19) [SIG Cloud Provider]
Fix a bug that DefaultPreemption plugin is disabled when using (legacy) scheduler policy. (#96439, @Huang-Wei) [SIG Scheduling and Testing]
Fix a bug where loadbalancer deletion gets stuck because of missing resource group. (#93962, @phiphi282)
Fix a concurrent map writes error in kubelet (#93773, @knight42) [SIG Node]
Fix a panic in kubectl debug when a pod has multiple init or ephemeral containers. (#94580, @kiyoshim55)
Fix a regression where kubeadm bails out with a fatal error when an optional version command line argument is supplied to the "kubeadm upgrade plan" command (#94421, @rosti) [SIG Cluster Lifecycle]
Fix azure disk attach failure for disk size bigger than 4TB (#95463, @andyzhangx) [SIG Cloud Provider]
Fix azure disk data loss issue on Windows when unmount disk (#95456, @andyzhangx) [SIG Cloud Provider and Storage]
Fix bug in JSON path parser where an error occurs when a range is empty (#95933, @brianpursley) [SIG API Machinery]
Fix client-go prometheus metrics to correctly present the API path accessed in some environments. (#74363, @aanm) [SIG API Machinery]
Fix detach azure disk issue when vm not exist (#95177, @andyzhangx) [SIG Cloud Provider]
Fix etcd_object_counts metric reported by kube-apiserver (#94773, @tkashem) [SIG API Machinery]
Fix incorrectly reported verbs for kube-apiserver metrics for CRD objects (#93523, @wojtek-t) [SIG API Machinery and Instrumentation]
Fix k8s.io/apimachinery/pkg/api/meta.SetStatusCondition to update ObservedGeneration (#95961, @KnicKnic) [SIG API Machinery]
Fix kubectl SchemaError on CRDs with schema using x-kubernetes-preserve-unknown-fields on array types. (#94888, @sttts) [SIG API Machinery]
Fix memory leak in kube-apiserver when underlying time goes forth and back. (#96266, @chenyw1990) [SIG API Machinery]
Fix missing csi annotations on node during parallel csinode update. (#94389, @pacoxu) [SIG Storage]
Fix network_programming_latency metric reporting for Endpoints/EndpointSlice deletions, where we don't have correct timestamp (#95363, @wojtek-t) [SIG Network and Scalability]
Fix paging issues when Azure API returns empty values with non-empty nextLink (#96211, @feiskyer) [SIG Cloud Provider]
Fix pull image error from multiple ACRs using azure managed identity (#96355, @andyzhangx) [SIG Cloud Provider]
Fix race condition on timeCache locks. (#94751, @auxten)
Fix regression on kubectl portforward when TCP and UCP services were configured on the same port. (#94728, @amorenoz)
Fix scheduler cache snapshot when a Node is deleted before its Pods (#95130, @alculquicondor) [SIG Scheduling]
Fix the cloudprovider_azure_api_request_duration_seconds metric buckets to correctly capture the latency metrics. Previously, the majority of the calls would fall in the "+Inf" bucket. (#94873, @marwanad) [SIG Cloud Provider and Instrumentation]
Fix vSphere volumes that could be erroneously attached to wrong node (#96224, @gnufied) [SIG Cloud Provider and Storage]
Fix verb & scope reporting for kube-apiserver metrics (LIST reported instead of GET) (#95562, @wojtek-t) [SIG API Machinery and Testing]
Fix vsphere detach failure for static PVs (#95447, @gnufied) [SIG Cloud Provider and Storage]
Fix: azure disk resize error if source does not exist (#93011, @andyzhangx) [SIG Cloud Provider]
Fix: detach azure disk broken on Azure Stack (#94885, @andyzhangx) [SIG Cloud Provider]
Fix: resize Azure disk issue when it's in attached state (#96705, @andyzhangx) [SIG Cloud Provider]
Fix: use sensitiveOptions on Windows mount (#94126, @andyzhangx) [SIG Cloud Provider and Storage]
Fixed a bug causing incorrect formatting of kubectl describe ingress. (#94985, @howardjohn) [SIG CLI and Network]
Fixed a bug in client-go where new clients with customized Dial, Proxy, GetCert config may get stale HTTP transports. (#95427, @roycaihw) [SIG API Machinery]
Fixed a bug that prevents kubectl to validate CRDs with schema using x-kubernetes-preserve-unknown-fields on object fields. (#96369, @gautierdelorme) [SIG API Machinery and Testing]
Fixed a bug that prevents the use of ephemeral containers in the presence of a validating admission webhook. (#94685, @verb) [SIG Node and Testing]
Fixed a bug where aggregator_unavailable_apiservice metrics were reported for deleted apiservices. (#96421, @dgrisonnet) [SIG API Machinery and Instrumentation]
Fixed a bug where improper storage and comparison of endpoints led to excessive API traffic from the endpoints controller (#94112, @damemi) [SIG Apps, Network and Testing]
Fixed a regression which prevented pods with docker/default seccomp annotations from being created in 1.19 if a PodSecurityPolicy was in place which did not allow runtime/default seccomp profiles. (#95985, @saschagrunert) [SIG Auth]
Fixed bug in reflector that couldn't recover from "Too large resource version" errors with API servers 1.17.0-1.18.5 (#94316, @janeczku) [SIG API Machinery]
Fixed bug where kubectl top pod output is not sorted when --sort-by and --containers flags are used together (#93692, @brianpursley) [SIG CLI]
Fixed kubelet creating extra sandbox for pods with RestartPolicyOnFailure after all containers succeeded (#92614, @tnqn) [SIG Node and Testing]
Fixes an issue proxying to ipv6 pods without specifying a port (#94834, @liggitt) [SIG API Machinery and Network]
Fixes code generation for non-namespaced create subresources fake client test. (#96586, @Doude) [SIG API Machinery]
Fixes high CPU usage in kubectl drain (#95260, @amandahla) [SIG CLI]
For vSphere Cloud Provider, If VM of worker node is deleted, the node will also be deleted by node controller (#92608, @lubronzhan) [SIG Cloud Provider]
Gracefully delete nodes when their parent scale set went missing (#95289, @bpineau) [SIG Cloud Provider]
HTTP/2 connection health check is enabled by default in all Kubernetes clients. The feature should work out-of-the-box. If needed, users can tune the feature via the HTTP2_READ_IDLE_TIMEOUT_SECONDS and HTTP2_PING_TIMEOUT_SECONDS environment variables. The feature is disabled if HTTP2_READ_IDLE_TIMEOUT_SECONDS is set to 0. (#95981, @caesarxuchao) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node]
If the user specifies an invalid timeout in the request URL, the request will be aborted with an HTTP 400.
If the user specifies a timeout in the request URL that exceeds the maximum request deadline allowed by the apiserver, the request will be aborted with an HTTP 400. (#96061, @tkashem) [SIG API Machinery, Network and Testing]
If we set SelectPolicy MinPolicySelect on scaleUp behavior or scaleDown behavior,Horizontal Pod Autoscaler doesn`t automatically scale the number of pods correctly (#95647, @JoshuaAndrew) [SIG Apps and Autoscaling]
Ignore apparmor for non-linux operating systems (#93220, @wawa0210) [SIG Node and Windows]
Ignore root user check when windows pod starts (#92355, @wawa0210) [SIG Node and Windows]
Improve error messages related to nodePort endpoint changes conntrack entries cleanup. (#96251, @ravens) [SIG Network]
In dual-stack clusters, kubelet will now set up both IPv4 and IPv6 iptables rules, which may
fix some problems, eg with HostPorts. (#94474, @danwinship) [SIG Network and Node]
Increase maximum IOPS of AWS EBS io1 volume to current maximum (64,000). (#90014, @jacobmarble)
K8s.io/apimachinery: runtime.DefaultUnstructuredConverter.FromUnstructured now handles converting integer fields to typed float values (#93250, @liggitt) [SIG API Machinery]
Kube-proxy now trims extra spaces found in loadBalancerSourceRanges to match Service validation. (#94107, @robscott) [SIG Network]
Kubeadm ensures "kubeadm reset" does not unmount the root "/var/lib/kubelet" directory if it is mounted by the user. (#93702, @thtanaka)
Kubeadm now makes sure the etcd manifest is regenerated upon upgrade even when no etcd version change takes place (#94395, @rosti) [SIG Cluster Lifecycle]
Kubeadm now warns (instead of error out) on missing "ca.key" files for root CA, front-proxy CA and etcd CA, during "kubeadm join --control-plane" if the user has provided all certificates, keys and kubeconfig files which require signing with the given CA keys. (#94988, @neolit123)
Kubeadm: add missing "--experimental-patches" flag to "kubeadm init phase control-plane" (#95786, @Sh4d1) [SIG Cluster Lifecycle]
Kubeadm: avoid a panic when determining if the running version of CoreDNS is supported during upgrades (#94299, @zouyee) [SIG Cluster Lifecycle]
Kubeadm: ensure the etcd data directory is created with 0700 permissions during control-plane init and join (#94102, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: fix coredns migration should be triggered when there are newdefault configs during kubeadm upgrade (#96907, @pacoxu) [SIG Cluster Lifecycle]
Kubeadm: fix the bug that kubeadm tries to call 'docker info' even if the CRI socket was for another CR (#94555, @SataQiu) [SIG Cluster Lifecycle]
Kubeadm: for Docker as the container runtime, make the "kubeadm reset" command stop containers before removing them (#94586, @BedivereZero) [SIG Cluster Lifecycle]
Kubeadm: relax the validation of kubeconfig server URLs. Allow the user to define custom kubeconfig server URLs without erroring out during validation of existing kubeconfig files (e.g. when using external CA mode). (#94816, @neolit123) [SIG Cluster Lifecycle]
Kubectl: print error if users place flags before plugin name (#92343, @knight42) [SIG CLI]
Kubelet: assume that swap is disabled when /proc/swaps does not exist (#93931, @SataQiu) [SIG Node]
New Azure instance types do now have correct max data disk count information. (#94340, @ialidzhikov) [SIG Cloud Provider and Storage]
Port mapping now allows the same containerPort of different containers to different hostPort without naming the mapping explicitly. (#94494, @SergeyKanzhelev)
Print go stack traces at -v=4 and not -v=2 (#94663, @soltysh) [SIG CLI]
Recreate EndpointSlices on rapid Service creation. (#94730, @robscott)
Reduce volume name length for vsphere volumes (#96533, @gnufied) [SIG Storage]
Remove ready file and its directory (which is created during volume SetUp) during emptyDir volume TearDown. (#95770, @jingxu97) [SIG Storage]
Reorganized iptables rules to fix a performance issue (#95252, @tssurya) [SIG Network]
Require feature flag CustomCPUCFSQuotaPeriod if setting a non-default cpuCFSQuotaPeriod in kubelet config. (#94687, @karan) [SIG Node]
Resolves a regression in 1.19+ with workloads targeting deprecated beta os/arch labels getting stuck in NodeAffinity status on node startup. (#96810, @liggitt) [SIG Node]
Resolves non-deterministic behavior of the garbage collection controller when ownerReferences with incorrect data are encountered. Events with a reason of OwnerRefInvalidNamespace are recorded when namespace mismatches between child and owner objects are detected. The kubectl-check-ownerreferences tool can be run prior to upgrading to locate existing objects with invalid ownerReferences.
A namespaced object with an ownerReference referencing a uid of a namespaced kind which does not exist in the same namespace is now consistently treated as though that owner does not exist, and the child object is deleted.
A cluster-scoped object with an ownerReference referencing a uid of a namespaced kind is now consistently treated as though that owner is not resolvable, and the child object is ignored by the garbage collector. (#92743, @liggitt) [SIG API Machinery, Apps and Testing]
Skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:162]: Driver azure-disk doesn't support snapshot type DynamicSnapshot -- skipping
skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:185]: Driver azure-disk doesn't support ntfs -- skipping (#96144, @qinpingli) [SIG Storage and Testing]
StatefulSet Controller now waits for PersistentVolumeClaim deletion before creating pods. (#93457, @ymmt2005)
StreamWatcher now calls HandleCrash at appropriate sequence. (#93108, @lixiaobing1)
Support the node label node.kubernetes.io/exclude-from-external-load-balancers (#95542, @nilo19) [SIG Cloud Provider]
The AWS network load balancer attributes can now be specified during service creation (#95247, @kishorj) [SIG Cloud Provider]
The /debug/api_priority_and_fairness/dump_requests path at an apiserver will no longer return a phantom line for each exempt priority level. (#93406, @MikeSpreitzer) [SIG API Machinery]
The kube-apiserver will no longer serve APIs that should have been deleted in GA non-alpha levels. Alpha levels will continue to serve the removed APIs so that CI doesn't immediately break. (#96525, @deads2k) [SIG API Machinery]
The kubelet recognizes the --containerd-namespace flag to configure the namespace used by cadvisor. (#87054, @changyaowei) [SIG Node]
Unhealthy pods covered by PDBs can be successfully evicted if enough healthy pods are available. (#94381, @michaelgugino) [SIG Apps]
Update Calico to v3.15.2 (#94241, @lmm) [SIG Cloud Provider]
Update default etcd server version to 3.4.13 (#94287, @jingyih) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing]
Update max azure data disk count map (#96308, @andyzhangx) [SIG Cloud Provider and Storage]
Update the PIP when it is not in the Succeeded provisioning state during the LB update. (#95748, @nilo19) [SIG Cloud Provider]
Update the frontend IP config when the service's pipName annotation is changed (#95813, @nilo19) [SIG Cloud Provider]
Update the route table tag in the route reconcile loop (#96545, @nilo19) [SIG Cloud Provider]
Use NLB Subnet CIDRs instead of VPC CIDRs in Health Check SG Rules (#93515, @t0rr3sp3dr0) [SIG Cloud Provider]
Users will see increase in time for deletion of pods and also guarantee that removal of pod from api server would mean deletion of all the resources from container runtime. (#92817, @kmala) [SIG Node]
Very large patches may now be specified to kubectl patch with the --patch-file flag instead of including them directly on the command line. The --patch and --patch-file flags are mutually exclusive. (#93548, @smarterclayton) [SIG CLI]
Volume binding: report UnschedulableAndUnresolvable status instead of an error when bound PVs not found (#95541, @cofyc) [SIG Apps, Scheduling and Storage]
Warn instead of fail when creating Roles and ClusterRoles with custom verbs via kubectl (#92492, @eddiezane) [SIG CLI]
When creating a PVC with the volume.beta.kubernetes.io/storage-provisioner annotation already set, the PV controller might have incorrectly deleted the newly provisioned PV instead of binding it to the PVC, depending on timing and system load. (#95909, @pohly) [SIG Apps and Storage]
[kubectl] Fail when local source file doesn't exist (#90333, @bamarni) [SIG CLI]
--redirect-container-streaming is no longer functional. The flag will be removed in v1.22 (#95935, @tallclair) [SIG Node]
A new metric requestAbortsTotal has been introduced that counts aborted requests for each group, version, verb, resource, subresource and scope. (#95002, @p0lyn0mial) [SIG API Machinery, Cloud Provider, Instrumentation and Scheduling]
API priority and fairness metrics use snake_case in label names (#96236, @adtac) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Testing]
Add fine grained debugging to intra-pod conformance test to troubleshoot networking issues for potentially unhealthy nodes when running conformance or sonobuoy tests. (#93837, @jayunit100)
Adds a bootstrapping ClusterRole, ClusterRoleBinding and group for /metrics, /livez/, /readyz/, & /healthz/- endpoints. (#93311, @logicalhan) [SIG API Machinery, Auth, Cloud Provider and Instrumentation]
AdmissionReview objects sent for the creation of Namespace API objects now populate the namespace attribute consistently (previously the namespace attribute was empty for Namespace creation via POST requests, and populated for Namespace creation via server-side-apply PATCH requests) (#95012, @nodo) [SIG API Machinery and Testing]
Applies translations on all command descriptions (#95439, @HerrNaN) [SIG CLI]
Base-images: Update to debian-iptables:buster-v1.3.0
Uses iptables 1.8.5
base-images: Update to debian-base:buster-v1.2.0
cluster/images/etcd: Build etcd:3.4.13-1 image
Uses debian-base:buster-v1.2.0 (#94733, @justaugustus) [SIG API Machinery, Release and Testing]
Client-go header logging (at verbosity levels >= 9) now masks Authorization header contents (#95316, @sfowl) [SIG API Machinery]
Decrease warning message frequency on setting volume ownership for configmap/secret. (#92878, @jvanz)
Enhance log information of verifyRunAsNonRoot, add pod, container information (#94911, @wawa0210) [SIG Node]
Fix func name NewCreateCreateDeploymentOptions (#91931, @lixiaobing1) [SIG CLI]
Fix kubelet to properly log when a container is started. Previously, kubelet may log that container is dead and was restarted when it was actually started for the first time. This behavior only happened on pods with initContainers and regular containers. (#91469, @rata)
Fixes the message about no auth for metrics in scheduler. (#94035, @zhouya0) [SIG Scheduling]
Generators for services are removed from kubectl (#95256, @Git-Jiro) [SIG CLI]
Introduce kubectl-convert plugin. (#96190, @soltysh) [SIG CLI and Testing]
Kube-scheduler now logs processed component config at startup (#96426, @damemi) [SIG Scheduling]
Kubeadm: Separate argument key/value in log msg (#94016, @mrueg) [SIG Cluster Lifecycle]
Kubeadm: remove the CoreDNS check for known image digests when applying the addon (#94506, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: update the default pause image version to 1.4.0 on Windows. With this update the image supports Windows versions 1809 (2019LTS), 1903, 1909, 2004 (#95419, @jsturtevant) [SIG Cluster Lifecycle and Windows]
Kubectl: the generator flag of kubectl autoscale has been deprecated and has no effect, it will be removed in a feature release (#92998, @SataQiu) [SIG CLI]
Lock ExternalPolicyForExternalIP to default, this feature gate will be removed in 1.22. (#94581, @knabben) [SIG Network]
Mask ceph RBD adminSecrets in logs when logLevel >= 4. (#95245, @sfowl)
Remove offensive words from kubectl cluster-info command. (#95202, @rikatz)
Remove the dependency of csi-translation-lib module on apiserver/cloud-provider/controller-manager (#95543, @wawa0210) [SIG Release]
Scheduler framework interface moved from pkg/scheduler/framework/v1alpha to pkg/scheduler/framework (#95069, @farah) [SIG Scheduling, Storage and Testing]
Service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset is removed. All Standard load balancers will always enable tcp resets. (#94297, @MarcPow) [SIG Cloud Provider]
Stop propagating SelfLink (deprecated in 1.16) in kube-apiserver (#94397, @wojtek-t) [SIG API Machinery and Testing]
Strip unnecessary security contexts on Windows (#93475, @ravisantoshgudimetla) [SIG Node, Testing and Windows]
To ensure the code be strong, add unit test for GetAddressAndDialer (#93180, @FreeZhang61) [SIG Node]
UDP and SCTP protocols can left stale connections that need to be cleared to avoid services disruption, but they can cause problems that are hard to debug.
Kubernetes components using a loglevel greater or equal than 4 will log the conntrack operations and its output, to show the entries that were deleted. (#95694, @aojea) [SIG Network]
Update CNI plugins to v0.8.7 (#94367, @justaugustus) [SIG Cloud Provider, Network, Node, Release and Testing]
Update etcd client side to v3.4.13 (#94259, @jingyih) [SIG API Machinery and Cloud Provider]
Users will now be able to configure all supported values for AWS NLB health check interval and thresholds for new resources. (#96312, @kishorj) [SIG Cloud Provider]
V1helpers.MatchNodeSelectorTerms now accepts just a Node and a list of Terms (#95871, @damemi) [SIG Apps, Scheduling and Storage]
MatchNodeSelectorTerms function moved to k8s.io/component-helpers (#95531, @damemi) [SIG Apps, Scheduling and Storage]
kubectl api-resources now prints the API version (as 'API group/version', same as output of kubectl api-versions). The column APIGROUP is now APIVERSION (#95253, @sallyom) [SIG CLI]
kubectl get ingress now prefers the networking.k8s.io/v1 over extensions/v1beta1 (deprecated since v1.14). To explicitly request the deprecated version, use kubectl get ingress.v1beta1.extensions. (#94309, @liggitt) [SIG API Machinery and CLI]
Resolves an issue running Ingress conformance tests on clusters which use finalizers on Ingress objects to manage releasing load balancer resources (#96742, @spencerhance) [SIG Network and Testing]
The Conformance test "validates that there is no conflict between pods with same hostPort but different hostIP and protocol" now validates the connectivity to each hostPort, in addition to the functionality. (#96627, @aojea) [SIG Scheduling and Testing]
Bug or Regression
Bump node-problem-detector version to v0.8.5 to fix OOM detection in with Linux kernels 5.1+ (#96716, @tosi3k) [SIG Cloud Provider, Scalability and Testing]
Changes to timeout parameter handling in 1.20.0-beta.2 have been reverted to avoid breaking backwards compatibility with existing clients. (#96727, @liggitt) [SIG API Machinery and Testing]
Duplicate owner reference entries in create/update/patch requests now get deduplicated by the API server. The client sending the request now receives a warning header in the API response. Clients should stop sending requests with duplicate owner references. The API server may reject such requests as early as 1.24. (#96185, @roycaihw) [SIG API Machinery and Testing]
Fix: resize Azure disk issue when it's in attached state (#96705, @andyzhangx) [SIG Cloud Provider]
Fixed a bug where aggregator_unavailable_apiservice metrics were reported for deleted apiservices. (#96421, @dgrisonnet) [SIG API Machinery and Instrumentation]
Fixes code generation for non-namespaced create subresources fake client test. (#96586, @Doude) [SIG API Machinery]
HTTP/2 connection health check is enabled by default in all Kubernetes clients. The feature should work out-of-the-box. If needed, users can tune the feature via the HTTP2_READ_IDLE_TIMEOUT_SECONDS and HTTP2_PING_TIMEOUT_SECONDS environment variables. The feature is disabled if HTTP2_READ_IDLE_TIMEOUT_SECONDS is set to 0. (#95981, @caesarxuchao) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node]
Kubeadm: fix coredns migration should be triggered when there are newdefault configs during kubeadm upgrade (#96907, @pacoxu) [SIG Cluster Lifecycle]
Reduce volume name length for vsphere volumes (#96533, @gnufied) [SIG Storage]
Resolves a regression in 1.19+ with workloads targeting deprecated beta os/arch labels getting stuck in NodeAffinity status on node startup. (#96810, @liggitt) [SIG Node]
(No, really, you MUST read this before you upgrade)
A bug was fixed in kubelet where exec probe timeouts were not respected. Ensure that pods relying on this behavior are updated to correctly handle probe timeouts.
This change in behavior may be unexpected for some clusters and can be disabled by turning off the ExecProbeTimeout feature gate. This gate will be locked and removed in future releases so that exec probe timeouts are always respected. (#94115, @andrewsykim) [SIG Node and Testing]
For CSI drivers, kubelet no longer creates the target_path for NodePublishVolume in accordance with the CSI spec. Kubelet also no longer checks if staging and target paths are mounts or corrupted. CSI drivers need to be idempotent and do any necessary mount verification. (#88759, @andyzhangx) [SIG Storage]
Kubeadm:
The label applied to control-plane nodes "node-role.kubernetes.io/master" is now deprecated and will be removed in a future release after a GA deprecation period.
Introduce a new label "node-role.kubernetes.io/control-plane" that will be applied in parallel to "node-role.kubernetes.io/master" until the removal of the "node-role.kubernetes.io/master" label.
Make "kubeadm upgrade apply" add the "node-role.kubernetes.io/control-plane" label on existing nodes that only have the "node-role.kubernetes.io/master" label during upgrade.
Please adapt your tooling built on top of kubeadm to use the "node-role.kubernetes.io/control-plane" label.
The taint applied to control-plane nodes "node-role.kubernetes.io/master:NoSchedule" is now deprecated and will be removed in a future release after a GA deprecation period.
Apply toleration for a new, future taint "node-role.kubernetes.io/control-plane:NoSchedule" to the kubeadm CoreDNS / kube-dns managed manifests. Note that this taint is not yet applied to kubeadm control-plane nodes.
Please adapt your workloads to tolerate the same future taint preemptively.
Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]
API priority and fairness graduated to beta
1.19 servers with APF turned on should not be run in a multi-server cluster with 1.20+ servers. (#96527, @adtac) [SIG API Machinery and Testing]
Add WindowsContainerResources and Annotations to CRI-API UpdateContainerResourcesRequest (#95741, @katiewasnothere) [SIG Node]
Add a 'serving' and terminating condition to the EndpointSlice API.
serving tracks the readiness of endpoints regardless of their terminating state. This is distinct from ready since ready is only true when pods are not terminating.
terminating is true when an endpoint is terminating. For pods this is any endpoint with a deletion timestamp. (#92968, @andrewsykim) [SIG Apps and Network]
Add support for hugepages to downward API (#86102, @derekwaynecarr) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing]
Adds kubelet alpha feature, GracefulNodeShutdown which makes kubelet aware of node system shutdowns and result in graceful termination of pods during a system shutdown. (#96129, @bobbypage) [SIG Node]
AppProtocol is now GA for Endpoints and Services. The ServiceAppProtocol feature gate will be deprecated in 1.21. (#96327, @robscott) [SIG Apps and Network]
Automatic allocation of NodePorts for services with type LoadBalancer can now be disabled by setting the (new) parameter
Service.spec.allocateLoadBalancerNodePorts=false. The default is to allocate NodePorts for services with type LoadBalancer which is the existing behavior. (#92744, @uablrek) [SIG Apps and Network]
Document that ServiceTopology feature is required to use service.spec.topologyKeys. (#96528, @andrewsykim) [SIG Apps]
EndpointSlice has a new NodeName field guarded by the EndpointSliceNodeName feature gate.
EndpointSlice topology field will be deprecated in an upcoming release.
EndpointSlice "IP" address type is formally removed after being deprecated in Kubernetes 1.17.
The discovery.k8s.io/v1alpha1 API is deprecated and will be removed in Kubernetes 1.21. (#96440, @robscott) [SIG API Machinery, Apps and Network]
Fewer candidates are enumerated for preemption to improve performance in large clusters (#94814, @adtac) [SIG Scheduling]
If BoundServiceAccountTokenVolume is enabled, cluster admins can use metric serviceaccount_stale_tokens_total to monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off extended tokens by starting kube-apiserver with flag --service-account-extend-token-expiration=false (#96273, @zshihang) [SIG API Machinery and Auth]
Introduce alpha support for exec-based container registry credential provider plugins in the kubelet. (#94196, @andrewsykim) [SIG Node and Release]
Kube-apiserver now deletes expired kube-apiserver Lease objects:
The feature is under feature gate APIServerIdentity.
A flag is added to kube-apiserver: identity-lease-garbage-collection-check-period-seconds (#95895, @roycaihw) [SIG API Machinery, Apps, Auth and Testing]
Move configurable fsgroup change policy for pods to beta (#96376, @gnufied) [SIG Apps and Storage]
New flag is introduced, i.e. --topology-manager-scope=container|pod.
The default value is the "container" scope. (#92967, @cezaryzukowski) [SIG Instrumentation, Node and Testing]
NodeAffinity plugin can be configured with AddedAffinity. (#96202, @alculquicondor) [SIG Node, Scheduling and Testing]
Promote RuntimeClass feature to GA.
Promote node.k8s.io API groups from v1beta1 to v1. (#95718, @SergeyKanzhelev) [SIG Apps, Auth, Node, Scheduling and Testing]
Reminder: The labels "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" are deprecated in favor of "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" respectively. All users of the "failure-domain.beta..." labels should switch to the "topology..." equivalents. (#96033, @thockin) [SIG API Machinery, Apps, CLI, Cloud Provider, Network, Node, Scheduling, Storage and Testing]
The usage of mixed protocol values in the same LoadBalancer Service is possible if the new feature gate MixedProtocolLBSVC is enabled.
"action required"
The feature gate is disabled by default. The user has to enable it for the API Server. (#94028, @janosi) [SIG API Machinery and Apps]
This PR will introduce a feature gate CSIServiceAccountToken with two additional fields in CSIDriverSpec. (#93130, @zshihang) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing]
Users can try the cronjob controller v2 using the feature gate. This will be the default controller in future releases. (#93370, @alaypatel07) [SIG API Machinery, Apps, Auth and Testing]
VolumeSnapshotDataSource moves to GA in 1.20 release (#95282, @xing-yang) [SIG Apps]
Feature
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: (#95896, @zshihang) [SIG API Machinery and Cluster Lifecycle]
A new set of alpha metrics are reported by the Kubernetes scheduler under the /metrics/resources endpoint that allow administrators to easily see the resource consumption (requests and limits for all resources on the pods) and compare it to actual pod usage or node capacity. (#94866, @smarterclayton) [SIG API Machinery, Instrumentation, Node and Scheduling]
Add --experimental-logging-sanitization flag enabling runtime protection from leaking sensitive data in logs (#96370, @serathius) [SIG API Machinery, Cluster Lifecycle and Instrumentation]
Add a StorageVersionAPI feature gate that makes API server update storageversions before serving certain write requests.
This feature allows the storage migrator to manage storage migration for built-in resources.
Enabling internal.apiserver.k8s.io/v1alpha1 API and APIServerIdentity feature gate are required to use this feature. (#93873, @roycaihw) [SIG API Machinery, Auth and Testing]
Add a new vSphere metric: cloudprovider_vsphere_vcenter_versions. It's content show vCenter hostnames with the associated server version. (#94526, @Danil-Grigorev) [SIG Cloud Provider and Instrumentation]
Add feature to size memory backed volumes (#94444, @derekwaynecarr) [SIG Storage and Testing]
Add node_authorizer_actions_duration_seconds metric that can be used to estimate load to node authorizer. (#92466, @mborsz) [SIG API Machinery, Auth and Instrumentation]
Add pod_ based CPU and memory metrics to Kubelet's /metrics/resource endpoint (#95839, @egernst) [SIG Instrumentation, Node and Testing]
Adds a headless service on node-local-cache addon. (#88412, @stafot) [SIG Cloud Provider and Network]
CRDs: For structural schemas, non-nullable null map fields will now be dropped and defaulted if a default is available. null items in list will continue being preserved, and fail validation if not nullable. (#95423, @apelisse) [SIG API Machinery]
E2e test for PodFsGroupChangePolicy (#96247, @saikat-royc) [SIG Storage and Testing]
Gradudate the Pod Resources API to G.A
Introduces the pod_resources_endpoint_requests_total metric which tracks the total number of requests to the pod resources API (#92165, @RenaudWasTaken) [SIG Instrumentation, Node and Testing]
Introduce api-extensions category which will return: mutating admission configs, validating admission configs, CRDs and APIServices when used in kubectl get, for example. (#95603, @soltysh) [SIG API Machinery]
Kube-apiserver now maintains a Lease object to identify itself:
The feature is under feature gate APIServerIdentity.
Two flags are added to kube-apiserver: identity-lease-duration-seconds, identity-lease-renew-interval-seconds (#95533, @roycaihw) [SIG API Machinery]
Kube-apiserver: The timeout used when making health check calls to etcd can now be configured with --etcd-healthcheck-timeout. The default timeout is 2 seconds, matching the previous behavior. (#93244, @Sh4d1) [SIG API Machinery]
Kubectl: Previously users cannot provide arguments to a external diff tool via KUBECTL_EXTERNAL_DIFF env. This release now allow users to specify args to KUBECTL_EXTERNAL_DIFF env. (#95292, @dougsland) [SIG CLI]
Scheduler now ignores Pod update events if the resourceVersion of old and new Pods are identical. (#96071, @Huang-Wei) [SIG Scheduling]
Support custom tags for cloud provider managed resources (#96450, @nilo19) [SIG Cloud Provider]
Support customize load balancer health probe protocol and request path (#96338, @nilo19) [SIG Cloud Provider]
Support multiple standard load balancers in one cluster (#96111, @nilo19) [SIG Cloud Provider]
The beta RootCAConfigMap feature gate is enabled by default and causes kube-controller-manager to publish a "kube-root-ca.crt" ConfigMap to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver. (#96197, @zshihang) [SIG API Machinery, Apps, Auth and Testing]
The kubelet_runtime_operations_duration_seconds metric got additional buckets of 60, 300, 600, 900 and 1200 seconds (#96054, @alvaroaleman) [SIG Instrumentation and Node]
There is a new pv_collector_total_pv_count metric that counts persistent volumes by the volume plugin name and volume mode. (#95719, @tsmetana) [SIG Apps, Instrumentation, Storage and Testing]
Volume snapshot e2e test to validate PVC and VolumeSnapshotContent finalizer (#95863, @RaunakShah) [SIG Cloud Provider, Storage and Testing]
Warns user when executing kubectl apply/diff to resource currently being deleted. (#95544, @SaiHarshaK) [SIG CLI]
kubectl alpha debug has graduated to beta and is now kubectl debug. (#96138, @verb) [SIG CLI and Testing]
kubectl debug gains support for changing container images when copying a pod for debugging, similar to how kubectl set image works. See kubectl help debug for more information. (#96058, @verb) [SIG CLI]
Documentation
Updates docs and guidance on cloud provider InstancesV2 and Zones interface for external cloud providers:
removes experimental warning for InstancesV2
document that implementation of InstancesV2 will disable calls to Zones
deprecate Zones in favor of InstancesV2 (#96397, @andrewsykim) [SIG Cloud Provider]
Bug or Regression
Change plugin name in fsgroupapplymetrics of csi and flexvolume to distinguish different driver (#95892, @JornShen) [SIG Instrumentation, Storage and Testing]
Clear UDP conntrack entry on endpoint changes when using nodeport (#71573, @JacobTanenbaum) [SIG Network]
Exposes and sets a default timeout for the TokenReview client for DelegatingAuthenticationOptions (#96217, @p0lyn0mial) [SIG API Machinery and Cloud Provider]
Fix CVE-2020-8555 for Quobyte client connections. (#95206, @misterikkit) [SIG Storage]
Fix IP fragmentation of UDP and TCP packets not supported issues on LoadBalancer rules (#96464, @nilo19) [SIG Cloud Provider]
Fix a bug that DefaultPreemption plugin is disabled when using (legacy) scheduler policy. (#96439, @Huang-Wei) [SIG Scheduling and Testing]
Fix bug in JSON path parser where an error occurs when a range is empty (#95933, @brianpursley) [SIG API Machinery]
Fix client-go prometheus metrics to correctly present the API path accessed in some environments. (#74363, @aanm) [SIG API Machinery]
Fix memory leak in kube-apiserver when underlying time goes forth and back. (#96266, @chenyw1990) [SIG API Machinery]
Fix paging issues when Azure API returns empty values with non-empty nextLink (#96211, @feiskyer) [SIG Cloud Provider]
Fix pull image error from multiple ACRs using azure managed identity (#96355, @andyzhangx) [SIG Cloud Provider]
Fix vSphere volumes that could be erroneously attached to wrong node (#96224, @gnufied) [SIG Cloud Provider and Storage]
Fixed a bug that prevents kubectl to validate CRDs with schema using x-kubernetes-preserve-unknown-fields on object fields. (#96369, @gautierdelorme) [SIG API Machinery and Testing]
For vSphere Cloud Provider, If VM of worker node is deleted, the node will also be deleted by node controller (#92608, @lubronzhan) [SIG Cloud Provider]
HTTP/2 connection health check is enabled by default in all Kubernetes clients. The feature should work out-of-the-box. If needed, users can tune the feature via the HTTP2_READ_IDLE_TIMEOUT_SECONDS and HTTP2_PING_TIMEOUT_SECONDS environment variables. The feature is disabled if HTTP2_READ_IDLE_TIMEOUT_SECONDS is set to 0. (#95981, @caesarxuchao) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node]
If the user specifies an invalid timeout in the request URL, the request will be aborted with an HTTP 400.
If the user specifies a timeout in the request URL that exceeds the maximum request deadline allowed by the apiserver, the request will be aborted with an HTTP 400. (#96061, @tkashem) [SIG API Machinery, Network and Testing]
Improve error messages related to nodePort endpoint changes conntrack entries cleanup. (#96251, @ravens) [SIG Network]
Print go stack traces at -v=4 and not -v=2 (#94663, @soltysh) [SIG CLI]
Remove ready file and its directory (which is created during volume SetUp) during emptyDir volume TearDown. (#95770, @jingxu97) [SIG Storage]
Resolves non-deterministic behavior of the garbage collection controller when ownerReferences with incorrect data are encountered. Events with a reason of OwnerRefInvalidNamespace are recorded when namespace mismatches between child and owner objects are detected.
A namespaced object with an ownerReference referencing a uid of a namespaced kind which does not exist in the same namespace is now consistently treated as though that owner does not exist, and the child object is deleted.
A cluster-scoped object with an ownerReference referencing a uid of a namespaced kind is now consistently treated as though that owner is not resolvable, and the child object is ignored by the garbage collector. (#92743, @liggitt) [SIG API Machinery, Apps and Testing]
Skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:162]: Driver azure-disk doesn't support snapshot type DynamicSnapshot -- skipping
skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:185]: Driver azure-disk doesn't support ntfs -- skipping (#96144, @qinpingli) [SIG Storage and Testing]
The AWS network load balancer attributes can now be specified during service creation (#95247, @kishorj) [SIG Cloud Provider]
The kube-apiserver will no longer serve APIs that should have been deleted in GA non-alpha levels. Alpha levels will continue to serve the removed APIs so that CI doesn't immediately break. (#96525, @deads2k) [SIG API Machinery]
Update max azure data disk count map (#96308, @andyzhangx) [SIG Cloud Provider and Storage]
Update the route table tag in the route reconcile loop (#96545, @nilo19) [SIG Cloud Provider]
Volume binding: report UnschedulableAndUnresolvable status instead of an error when bound PVs not found (#95541, @cofyc) [SIG Apps, Scheduling and Storage]
[kubectl] Fail when local source file doesn't exist (#90333, @bamarni) [SIG CLI]
Other (Cleanup or Flake)
Handle slow cronjob lister in cronjob controller v2 and improve memory footprint. (#96443, @alaypatel07) [SIG Apps]
--redirect-container-streaming is no longer functional. The flag will be removed in v1.22 (#95935, @tallclair) [SIG Node]
A new metric requestAbortsTotal has been introduced that counts aborted requests for each group, version, verb, resource, subresource and scope. (#95002, @p0lyn0mial) [SIG API Machinery, Cloud Provider, Instrumentation and Scheduling]
API priority and fairness metrics use snake_case in label names (#96236, @adtac) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Testing]
Applies translations on all command descriptions (#95439, @HerrNaN) [SIG CLI]
Users will now be able to configure all supported values for AWS NLB health check interval and thresholds for new resources. (#96312, @kishorj) [SIG Cloud Provider]
ACTION REQUIRED: The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags --address and --insecure-bind-address have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags --port and --insecure-port may only be set to 0 and will be removed in v1.24. (#95856, @knight42) [SIG API Machinery, Node and Testing]
kubeadm's kube-apiserver Pod manifest now includes the following flags by default "--service-account-key-file", "--service-account-signing-key-file", "--service-account-issuer". (#93258, @zshihang) [SIG API Machinery, Auth, Cluster Lifecycle, Storage and Testing]
Certain fields on Service objects will be automatically cleared when changing the service's type to a mode that does not need those fields. For example, changing from type=LoadBalancer to type=ClusterIP will clear the NodePort assignments, rather than forcing the user to clear them. (#95196, @thockin) [SIG API Machinery, Apps, Network and Testing]
Services will now have a clusterIPs field to go with clusterIP. clusterIPs[0] is a synonym for clusterIP and will be syncronized on create and update operations. (#95894, @thockin) [SIG Network]
Feature
A new metric apiserver_request_filter_duration_seconds has been introduced that
measures request filter latency in seconds. (#95207, @tkashem) [SIG API Machinery and Instrumentation]
Add a new flag to set priority for the kubelet on Windows nodes so that workloads cannot overwhelm the node there by disrupting kubelet process. (#96051, @ravisantoshgudimetla) [SIG Node and Windows]
Client-go credential plugins can now be passed in the current cluster information via the KUBERNETES_EXEC_INFO environment variable. (#95489, @ankeesler) [SIG API Machinery and Auth]
Kube-apiserver: added support for compressing rotated audit log files with --audit-log-compress (#94066, @lojies) [SIG API Machinery and Auth]
Documentation
Fake dynamic client: document that List does not preserve TypeMeta in UnstructuredList (#95117, @andrewsykim) [SIG API Machinery]
Bug or Regression
Added support to kube-proxy for externalTrafficPolicy=Local setting via Direct Server Return (DSR) load balancers on Windows. (#93166, @elweb9858) [SIG Network]
Disable watchcache for events (#96052, @wojtek-t) [SIG API Machinery]
Disabled LocalStorageCapacityIsolation feature gate is honored during scheduling. (#96092, @Huang-Wei) [SIG Scheduling]
Fix bug in JSON path parser where an error occurs when a range is empty (#95933, @brianpursley) [SIG API Machinery]
Fix k8s.io/apimachinery/pkg/api/meta.SetStatusCondition to update ObservedGeneration (#95961, @KnicKnic) [SIG API Machinery]
Fixed a regression which prevented pods with docker/default seccomp annotations from being created in 1.19 if a PodSecurityPolicy was in place which did not allow runtime/default seccomp profiles. (#95985, @saschagrunert) [SIG Auth]
Kubectl: print error if users place flags before plugin name (#92343, @knight42) [SIG CLI]
When creating a PVC with the volume.beta.kubernetes.io/storage-provisioner annotation already set, the PV controller might have incorrectly deleted the newly provisioned PV instead of binding it to the PVC, depending on timing and system load. (#95909, @pohly) [SIG Apps and Storage]
Other (Cleanup or Flake)
Kubectl: the generator flag of kubectl autoscale has been deprecated and has no effect, it will be removed in a feature release (#92998, @SataQiu) [SIG CLI]
V1helpers.MatchNodeSelectorTerms now accepts just a Node and a list of Terms (#95871, @damemi) [SIG Apps, Scheduling and Storage]
MatchNodeSelectorTerms function moved to k8s.io/component-helpers (#95531, @damemi) [SIG Apps, Scheduling and Storage]
(No, really, you MUST read this before you upgrade)
Kubeadm: improve the validation of serviceSubnet and podSubnet.
ServiceSubnet has to be limited in size, due to implementation details, and the mask can not allocate more than 20 bits.
PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible.
kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly.
Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. (#95723, @aojea) [SIG Cluster Lifecycle]
Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 (#95505, @wawa0210) [SIG Node and Windows]
Changes by Kind
Deprecation
Support 'controlplane' as a valid EgressSelection type in the EgressSelectorConfiguration API. 'Master' is deprecated and will be removed in v1.22. (#95235, @andrewsykim) [SIG API Machinery]
API Change
Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API.
It changes the dual-stack API wrt Service from a single ipFamily field to 3
fields: ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack),
ipFamilies (a list of families assigned), and clusterIPs (inclusive of
clusterIP). Most users do not need to set anything at all, defaulting will
handle it for them. Services are single-stack unless the user asks for
dual-stack. This is all gated by the "IPv6DualStack" feature gate. (#91824, @khenidak) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing]
Introduces a metric source for HPAs which allows scaling based on container resource usage. (#90691, @arjunrn) [SIG API Machinery, Apps, Autoscaling and CLI]
Feature
Add a metric for time taken to perform recursive permission change (#95866, @JornShen) [SIG Instrumentation and Storage]
Allow cross compilation of kubernetes on different platforms. (#94403, @bnrjee) [SIG Release]
Command to start network proxy changes from 'KUBE_ENABLE_EGRESS_VIA_KONNECTIVITY_SERVICE ./cluster/kube-up.sh' to 'KUBE_ENABLE_KONNECTIVITY_SERVICE=true ./hack/kube-up.sh' (#92669, @Jefftree) [SIG Cloud Provider]
DefaultPodTopologySpread graduated to Beta. The feature gate is enabled by default. (#95631, @alculquicondor) [SIG Scheduling and Testing]
Kubernetes E2E test image manifest lists now contain Windows images. (#77398, @claudiubelu) [SIG Testing and Windows]
Support for Windows container images (OS Versions: 1809, 1903, 1909, 2004) was added the pause:3.4 image. (#91452, @claudiubelu) [SIG Node, Release and Windows]
Documentation
Fake dynamic client: document that List does not preserve TypeMeta in UnstructuredList (#95117, @andrewsykim) [SIG API Machinery]
Bug or Regression
Exposes and sets a default timeout for the SubjectAccessReview client for DelegatingAuthorizationOptions. (#95725, @p0lyn0mial) [SIG API Machinery and Cloud Provider]
Alter wording to describe pods using a pvc (#95635, @RaunakShah) [SIG CLI]
If we set SelectPolicy MinPolicySelect on scaleUp behavior or scaleDown behavior,Horizontal Pod Autoscaler doesn`t automatically scale the number of pods correctly (#95647, @JoshuaAndrew) [SIG Apps and Autoscaling]
Ignore apparmor for non-linux operating systems (#93220, @wawa0210) [SIG Node and Windows]
New parameter defaultingType for PodTopologySpread plugin allows to use k8s defined or user provided default constraints (#95048, @alculquicondor) [SIG Scheduling]
Feature
Added new k8s.io/component-helpers repository providing shared helper code for (core) components. (#92507, @ingvagabund) [SIG Apps, Node, Release and Scheduling]
Adds create ingress command to kubectl (#78153, @amimof) [SIG CLI and Network]
Kubectl create now supports creating ingress objects. (#94327, @rikatz) [SIG CLI and Network]
New default scheduling plugins order reduces scheduling and preemption latency when taints and node affinity are used (#95539, @soulxu) [SIG Scheduling]
SCTP support in API objects (Pod, Service, NetworkPolicy) is now GA.
Note that this has no effect on whether SCTP is enabled on nodes at the kernel level,
and note that some cloud platforms and network plugins do not support SCTP traffic. (#95566, @danwinship) [SIG Apps and Network]
Scheduling Framework: expose Run[Pre]ScorePlugins functions to PreemptionHandle which can be used in PostFilter extention point. (#93534, @everpeace) [SIG Scheduling and Testing]
SelectorSpreadPriority maps to PodTopologySpread plugin when DefaultPodTopologySpread feature is enabled (#95448, @alculquicondor) [SIG Scheduling]
SetHostnameAsFQDN has been graduated to Beta and therefore it is enabled by default. (#95267, @javidiaz) [SIG Node]
Bug or Regression
An issues preventing volume expand controller to annotate the PVC with volume.kubernetes.io/storage-resizer when the PVC StorageClass is already updated to the out-of-tree provisioner is now fixed. (#94489, @ialidzhikov) [SIG API Machinery, Apps and Storage]
Change the mount way from systemd to normal mount except ceph and glusterfs intree-volume. (#94916, @smileusd) [SIG Apps, Cloud Provider, Network, Node, Storage and Testing]
Fix azure disk attach failure for disk size bigger than 4TB (#95463, @andyzhangx) [SIG Cloud Provider]
Fix azure disk data loss issue on Windows when unmount disk (#95456, @andyzhangx) [SIG Cloud Provider and Storage]
Fix verb & scope reporting for kube-apiserver metrics (LIST reported instead of GET) (#95562, @wojtek-t) [SIG API Machinery and Testing]
Fix vsphere detach failure for static PVs (#95447, @gnufied) [SIG Cloud Provider and Storage]
Fixed a bug causing incorrect formatting of kubectl describe ingress. (#94985, @howardjohn) [SIG CLI and Network]
Fixed a bug in client-go where new clients with customized Dial, Proxy, GetCert config may get stale HTTP transports. (#95427, @roycaihw) [SIG API Machinery]
Fixes high CPU usage in kubectl drain (#95260, @amandahla) [SIG CLI]
Support the node label node.kubernetes.io/exclude-from-external-load-balancers (#95542, @nilo19) [SIG Cloud Provider]
Other (Cleanup or Flake)
Fix func name NewCreateCreateDeploymentOptions (#91931, @lixiaobing1) [SIG CLI]
Kubeadm: update the default pause image version to 1.4.0 on Windows. With this update the image supports Windows versions 1809 (2019LTS), 1903, 1909, 2004 (#95419, @jsturtevant) [SIG Cluster Lifecycle and Windows]
Upgrade snapshot controller to 3.0.0 (#95412, @saikat-royc) [SIG Cloud Provider]
Remove the dependency of csi-translation-lib module on apiserver/cloud-provider/controller-manager (#95543, @wawa0210) [SIG Release]
Scheduler framework interface moved from pkg/scheduler/framework/v1alpha to pkg/scheduler/framework (#95069, @farah) [SIG Scheduling, Storage and Testing]
UDP and SCTP protocols can left stale connections that need to be cleared to avoid services disruption, but they can cause problems that are hard to debug.
Kubernetes components using a loglevel greater or equal than 4 will log the conntrack operations and its output, to show the entries that were deleted. (#95694, @aojea) [SIG Network]
Action-required: kubeadm: graduate the "kubeadm alpha certs" command to a parent command "kubeadm certs". The command "kubeadm alpha certs" is deprecated and will be removed in a future release. Please migrate. (#94938, @yagonobre) [SIG Cluster Lifecycle]
Action-required: kubeadm: remove the deprecated feature --experimental-kustomize from kubeadm commands. The feature was replaced with --experimental-patches in 1.19. To migrate see the --help description for the --experimental-patches flag. (#94871, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: deprecate self-hosting support. The experimental command "kubeadm alpha self-hosting" is now deprecated and will be removed in a future release. (#95125, @neolit123) [SIG Cluster Lifecycle]
Scheduler alpha metrics binding_duration_seconds and scheduling_algorithm_preemption_evaluation_seconds are deprecated, Both of those metrics are now covered as part of framework_extension_point_duration_seconds, the former as a PostFilter the latter and a Bind plugin. The plan is to remove both in 1.21 (#95001, @arghya88) [SIG Instrumentation and Scheduling]
API Change
GPU metrics provided by kubelet are now disabled by default (#95184, @RenaudWasTaken) [SIG Node]
New parameter defaultingType for PodTopologySpread plugin allows to use k8s defined or user provided default constraints (#95048, @alculquicondor) [SIG Scheduling]
Server Side Apply now treats LabelSelector fields as atomic (meaning the entire selector is managed by a single writer and updated together), since they contain interrelated and inseparable fields that do not merge in intuitive ways. (#93901, @jpbetz) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Storage and Testing]
Status of v1beta1 CRDs without "preserveUnknownFields:false" will show violation "spec.preserveUnknownFields: Invalid value: true: must be false" (#93078, @vareti) [SIG API Machinery]
Feature
Added get-users and delete-user to the kubectl config subcommand (#89840, @eddiezane) [SIG CLI]
Added counter metric "apiserver_request_self" to count API server self-requests with labels for verb, resource, and subresource. (#94288, @LogicalShark) [SIG API Machinery, Auth, Instrumentation and Scheduling]
Added new k8s.io/component-helpers repository providing shared helper code for (core) components. (#92507, @ingvagabund) [SIG Apps, Node, Release and Scheduling]
Adds create ingress command to kubectl (#78153, @amimof) [SIG CLI and Network]
Allow configuring AWS LoadBalancer health check protocol via service annotations (#94546, @kishorj) [SIG Cloud Provider]
Azure: Support multiple services sharing one IP address (#94991, @nilo19) [SIG Cloud Provider]
Ephemeral containers now apply the same API defaults as initContainers and containers (#94896, @wawa0210) [SIG Apps and CLI]
In dual-stack bare-metal clusters, you can now pass dual-stack IPs to kubelet --node-ip.
eg: kubelet --node-ip 10.1.0.5,fd01::0005. This is not yet supported for non-bare-metal
clusters.
In dual-stack clusters where nodes have dual-stack addresses, hostNetwork pods
will now get dual-stack PodIPs. (#95239, @danwinship) [SIG Network and Node]
Introduces a new GCE specific cluster creation variable KUBE_PROXY_DISABLE. When set to true, this will skip over the creation of kube-proxy (whether the daemonset or static pod). This can be used to control the lifecycle of kube-proxy separately from the lifecycle of the nodes. (#91977, @varunmar) [SIG Cloud Provider]
Kubeadm: do not throw errors if the current system time is outside of the NotBefore and NotAfter bounds of a loaded certificate. Print warnings instead. (#94504, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: make the command "kubeadm alpha kubeconfig user" accept a "--config" flag and remove the following flags:
apiserver-advertise-address / apiserver-bind-port: use either localAPIEndpoint from InitConfiguration or controlPlaneEndpoint from ClusterConfiguration.
cluster-name: use clusterName from ClusterConfiguration
cert-dir: use certificatesDir from ClusterConfiguration (#94879, @knight42) [SIG Cluster Lifecycle]
Kubectl rollout history sts/sts-name --revision=some-revision will start showing the detailed view of the sts on that specified revision (#86506, @dineshba) [SIG CLI]
Scheduling Framework: expose Run[Pre]ScorePlugins functions to PreemptionHandle which can be used in PostFilter extention point. (#93534, @everpeace) [SIG Scheduling and Testing]
Send gce node startup scripts logs to console and journal (#95311, @karan) [SIG Cloud Provider and Node]
Support kubectl delete orphan/foreground/background options (#93384, @zhouya0) [SIG CLI and Testing]
Bug or Regression
Change the mount way from systemd to normal mount except ceph and glusterfs intree-volume. (#94916, @smileusd) [SIG Apps, Cloud Provider, Network, Node, Storage and Testing]
Fix a bug where the endpoint slice controller was not mirroring the parent service labels to its corresponding endpoint slices (#94443, @aojea) [SIG Apps and Network]
Fix azure disk attach failure for disk size bigger than 4TB (#95463, @andyzhangx) [SIG Cloud Provider]
Fix azure disk data loss issue on Windows when unmount disk (#95456, @andyzhangx) [SIG Cloud Provider and Storage]
Fix detach azure disk issue when vm not exist (#95177, @andyzhangx) [SIG Cloud Provider]
Fix network_programming_latency metric reporting for Endpoints/EndpointSlice deletions, where we don't have correct timestamp (#95363, @wojtek-t) [SIG Network and Scalability]
Fix scheduler cache snapshot when a Node is deleted before its Pods (#95130, @alculquicondor) [SIG Scheduling]
Fix vsphere detach failure for static PVs (#95447, @gnufied) [SIG Cloud Provider and Storage]
Fixed a bug that prevents the use of ephemeral containers in the presence of a validating admission webhook. (#94685, @verb) [SIG Node and Testing]
Gracefully delete nodes when their parent scale set went missing (#95289, @bpineau) [SIG Cloud Provider]
In dual-stack clusters, kubelet will now set up both IPv4 and IPv6 iptables rules, which may
fix some problems, eg with HostPorts. (#94474, @danwinship) [SIG Network and Node]
Kubeadm: for Docker as the container runtime, make the "kubeadm reset" command stop containers before removing them (#94586, @BedivereZero) [SIG Cluster Lifecycle]
Kubeadm: warn but do not error out on missing "ca.key" files for root CA, front-proxy CA and etcd CA, during "kubeadm join --control-plane" if the user has provided all certificates, keys and kubeconfig files which require signing with the given CA keys. (#94988, @neolit123) [SIG Cluster Lifecycle]
Port mapping allows to map the same containerPort to multiple hostPort without naming the mapping explicitly. (#94494, @SergeyKanzhelev) [SIG Network and Node]
Warn instead of fail when creating Roles and ClusterRoles with custom verbs via kubectl (#92492, @eddiezane) [SIG CLI]
Other (Cleanup or Flake)
Added fine grained debugging to the intra-pod conformance test for helping easily resolve networking issues for nodes that might be unhealthy when running conformance or sonobuoy tests. (#93837, @jayunit100) [SIG Network and Testing]
AdmissionReview objects sent for the creation of Namespace API objects now populate the namespace attribute consistently (previously the namespace attribute was empty for Namespace creation via POST requests, and populated for Namespace creation via server-side-apply PATCH requests) (#95012, @nodo) [SIG API Machinery and Testing]
Client-go header logging (at verbosity levels >= 9) now masks Authorization header contents (#95316, @sfowl) [SIG API Machinery]
Enhance log information of verifyRunAsNonRoot, add pod, container information (#94911, @wawa0210) [SIG Node]
Errors from staticcheck: vendor/k8s.io/client-go/discovery/cached/memory/memcache_test.go:94:2: this value of g is never used (SA4006) (#95098, @phunziker) [SIG API Machinery]
Kubeadm: update the default pause image version to 1.4.0 on Windows. With this update the image supports Windows versions 1809 (2019LTS), 1903, 1909, 2004 (#95419, @jsturtevant) [SIG Cluster Lifecycle and Windows]
Masks ceph RBD adminSecrets in logs when logLevel >= 4 (#95245, @sfowl) [SIG Storage]
Upgrade snapshot controller to 3.0.0 (#95412, @saikat-royc) [SIG Cloud Provider]
Remove offensive words from kubectl cluster-info command (#95202, @rikatz) [SIG Architecture, CLI and Testing]
The following new metrics are available.
network_plugin_operations_total
network_plugin_operations_errors_total (#93066, @AnishShah) [SIG Instrumentation, Network and Node]
kubectl api-resources now prints the API version (as 'API group/version', same as output of kubectl api-versions). The column APIGROUP is now APIVERSION (#95253, @sallyom) [SIG CLI]
(No, really, you MUST read this before you upgrade)
Azure blob disk feature(kind: Shared, Dedicated) has been deprecated, you should use kind: Managed in kubernetes.io/azure-disk storage class. (#92905, @andyzhangx) [SIG Cloud Provider and Storage]
CVE-2020-8559 (Medium): Privilege escalation from compromised node to cluster. See https://github.com/kubernetes/kubernetes/issues/92914 for more details.
The API Server will no longer proxy non-101 responses for upgrade requests. This could break proxied backends (such as an extension API server) that respond to upgrade requests with a non-101 response code. (#92941, @tallclair) [SIG API Machinery]
Changes by Kind
Deprecation
Kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. (#93570, @liggitt) [SIG API Machinery, Apps and Cluster Lifecycle]
Kubeadm: deprecate the "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. (#92881, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: remove the deprecated "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. This change also removes the parent command "kubeadm alpha kubelet" as there are no more sub-commands under it for the time being. (#94668, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: remove the deprecated --kubelet-config flag for the command "kubeadm upgrade node" (#94869, @neolit123) [SIG Cluster Lifecycle]
Kubelet's deprecated endpoint metrics/resource/v1alpha1 has been removed, please adopt to metrics/resource. (#94272, @RainbowMango) [SIG Instrumentation and Node]
The v1alpha1 PodPreset API and admission plugin has been removed with no built-in replacement. Admission webhooks can be used to modify pods on creation. (#94090, @deads2k) [SIG API Machinery, Apps, CLI, Cloud Provider, Scalability and Testing]
API Change
A new nofuzz go build tag now disables gofuzz support. Release binaries enable this. (#92491, @BenTheElder) [SIG API Machinery]
A new alpha-level field, SupportsFsGroup, has been introduced for CSIDrivers to allow them to specify whether they support volume ownership and permission modifications. The CSIVolumeSupportFSGroup feature gate must be enabled to allow this field to be used. (#92001, @huffmanca) [SIG API Machinery, CLI and Storage]
Added pod version skew strategy for seccomp profile to synchronize the deprecated annotations with the new API Server fields. Please see the corresponding section in the KEP for more detailed explanations. (#91408, @saschagrunert) [SIG Apps, Auth, CLI and Node]
Adds the ability to disable Accelerator/GPU metrics collected by Kubelet (#91930, @RenaudWasTaken) [SIG Node]
Custom Endpoints are now mirrored to EndpointSlices by a new EndpointSliceMirroring controller. (#91637, @robscott) [SIG API Machinery, Apps, Auth, Cloud Provider, Instrumentation, Network and Testing]
External facing API podresources is now available under k8s.io/kubelet/pkg/apis/ (#92632, @RenaudWasTaken) [SIG Node and Testing]
Fix conversions for custom metrics. (#94481, @wojtek-t) [SIG API Machinery and Instrumentation]
Generic ephemeral volumes, a new alpha feature under the GenericEphemeralVolume feature gate, provide a more flexible alternative to EmptyDir volumes: as with EmptyDir, volumes are created and deleted for each pod automatically by Kubernetes. But because the normal provisioning process is used (PersistentVolumeClaim), storage can be provided by third-party storage vendors and all of the usual volume features work. Volumes don't need to be empt; for example, restoring from snapshot is supported. (#92784, @pohly) [SIG API Machinery, Apps, Auth, CLI, Instrumentation, Node, Scheduling, Storage and Testing]
Kube-controller-manager: volume plugins can be restricted from contacting local and loopback addresses by setting --volume-host-allow-local-loopback=false, or from contacting specific CIDR ranges by setting --volume-host-cidr-denylist (for example, --volume-host-cidr-denylist=127.0.0.1/28,feed::/16) (#91785, @mattcary) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing]
Kubernetes is now built with golang 1.15.0-rc.1.
The deprecated, legacy behavior of treating the CommonName field on X.509 serving certificates as a host name when no Subject Alternative Names are present is now disabled by default. It can be temporarily re-enabled by adding the value x509ignoreCN=0 to the GODEBUG environment variable. (#93264, @justaugustus) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Storage and Testing]
Migrate scheduler, controller-manager and cloud-controller-manager to use LeaseLock (#94603, @wojtek-t) [SIG API Machinery, Apps, Cloud Provider and Scheduling]
Modify DNS-1123 error messages to indicate that RFC 1123 is not followed exactly (#94182, @mattfenwick) [SIG API Machinery, Apps, Auth, Network and Node]
The ServiceAccountIssuerDiscovery feature gate is now Beta and enabled by default. (#91921, @mtaufen) [SIG Auth]
The kube-controller-manager managed signers can now have distinct signing certificates and keys. See the help about --cluster-signing-[signer-name]-{cert,key}-file. --cluster-signing-{cert,key}-file is still the default. (#90822, @deads2k) [SIG API Machinery, Apps and Auth]
When creating a networking.k8s.io/v1 Ingress API object, spec.tls[*].secretName values are required to pass validation rules for Secret API object names. (#93929, @liggitt) [SIG Network]
WinOverlay feature graduated to beta (#94807, @ksubrmnn) [SIG Windows]
Feature
ACTION REQUIRED : In CoreDNS v1.7.0, metrics names have been changed which will be backward incompatible with existing reporting formulas that use the old metrics' names. Adjust your formulas to the new names before upgrading.
Kubeadm now includes CoreDNS version v1.7.0. Some of the major changes include:
Fixed a bug that could cause CoreDNS to stop updating service records.
Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set.
Remove already deprecated options resyncperiod and upstream in the Kubernetes plugin.
Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names.
Add metrics for azure service operations (route and loadbalancer). (#94124, @nilo19) [SIG Cloud Provider and Instrumentation]
Add network rule support in Azure account creation (#94239, @andyzhangx) [SIG Cloud Provider]
Add tags support for Azure File Driver (#92825, @ZeroMagic) [SIG Cloud Provider and Storage]
Added kube-apiserver metrics: apiserver_current_inflight_request_measures and, when API Priority and Fairness is enable, windowed_request_stats. (#91177, @MikeSpreitzer) [SIG API Machinery, Instrumentation and Testing]
Audit events for API requests to deprecated API versions now include a "k8s.io/deprecated": "true" audit annotation. If a target removal release is identified, the audit event includes a "k8s.io/removal-release": "<majorVersion>.<minorVersion>" audit annotation as well. (#92842, @liggitt) [SIG API Machinery and Instrumentation]
Cloud node-controller use InstancesV2 (#91319, @gongguan) [SIG Apps, Cloud Provider, Scalability and Storage]
Kubeadm: Add a preflight check that the control-plane node has at least 1700MB of RAM (#93275, @xlgao-zju) [SIG Cluster Lifecycle]
Kubeadm: add the "--cluster-name" flag to the "kubeadm alpha kubeconfig user" to allow configuring the cluster name in the generated kubeconfig file (#93992, @prabhu43) [SIG Cluster Lifecycle]
Kubeadm: add the "--kubeconfig" flag to the "kubeadm init phase upload-certs" command to allow users to pass a custom location for a kubeconfig file. (#94765, @zhanw15) [SIG Cluster Lifecycle]
Kubeadm: deprecate the "--csr-only" and "--csr-dir" flags of the "kubeadm init phase certs" subcommands. Please use "kubeadm alpha certs generate-csr" instead. This new command allows you to generate new private keys and certificate signing requests for all the control-plane components, so that the certificates can be signed by an external CA. (#92183, @wallrj) [SIG Cluster Lifecycle]
Kubeadm: make etcd pod request 100m CPU, 100Mi memory and 100Mi ephemeral_storage by default (#94479, @knight42) [SIG Cluster Lifecycle]
Kubemark now supports both real and hollow nodes in a single cluster. (#93201, @ellistarn) [SIG Scalability]
build: Use go-runner:buster-v2.0.1 (built using go1.15.1)
bazel: Replace --features with Starlark build settings flag
hack/lib/util.sh: some bash cleanups
switched one spot to use kube::logging
make kube::util::find-binary return an error when it doesn't find
anything so that hack scripts fail fast instead of with '' binary not
found errors.
this required deleting some genfeddoc stuff. the binary no longer
exists in k/k repo since we removed federation/, and I don't see it
in https://github.com/kubernetes-sigs/kubefed/ either. I'm assuming
that it's gone for good now.
bazel: output go_binary rule directly from go_binary_conditional_pure
From: @mikedanese:
Instead of aliasing. Aliases are annoying in a number of ways. This is
specifically bugging me now because they make the action graph harder to
analyze programmatically. By using aliases here, we would need to handle
potentially aliased go_binary targets and dereference to the effective
target.
The comment references an issue with pure = select(...) which appears
to be resolved considering this now builds.
make kube::util::find-binary not dependent on bazel-out/ structure
Implement an aspect that outputs go_build_mode metadata for go binaries,
and use that during binary selection. (#94449, @justaugustus) [SIG Architecture, CLI, Cluster Lifecycle, Node, Release and Testing]
Only update Azure data disks when attach/detach (#94265, @andyzhangx) [SIG Cloud Provider]
Promote SupportNodePidsLimit to GA to provide node to pod pid isolation
Promote SupportPodPidsLimit to GA to provide ability to limit pids per pod (#94140, @derekwaynecarr) [SIG Node and Testing]
Rename pod_preemption_metrics to preemption_metrics. (#93256, @ahg-g) [SIG Instrumentation and Scheduling]
Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a replicas field from a user to an HPA without resetting to the default value are documented in Transferring Ownership (#92661, @jpbetz) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
Set CSIMigrationvSphere feature gates to beta.
Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver.
Requires: vSphere vCenter/ESXi Version: 7.0u1, HW Version: VM version 15 (#92816, @divyenpatel) [SIG Cloud Provider and Storage]
Support [service.beta.kubernetes.io/azure-pip-ip-tags] annotations to allow customers to specify ip-tags to influence public-ip creation in Azure [Tag1=Value1, Tag2=Value2, etc.] (#94114, @MarcPow) [SIG Cloud Provider]
Support a smooth upgrade from client-side apply to server-side apply without conflicts, as well as support the corresponding downgrade. (#90187, @julianvmodesto) [SIG API Machinery and Testing]
Trace output in apiserver logs is more organized and comprehensive. Traces are nested, and for all non-long running request endpoints, the entire filter chain is instrumented (e.g. authentication check is included). (#88936, @jpbetz) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Scheduling]
kubectl alpha debug now supports debugging nodes by creating a debugging container running in the node's host namespaces. (#92310, @verb) [SIG CLI]
Documentation
Kubelet: remove alpha warnings for CNI flags. (#94508, @andrewsykim) [SIG Network and Node]
Failing Test
Kube-proxy iptables min-sync-period defaults to 1 sec. Previously, it was 0. (#92836, @aojea) [SIG Network]
Bug or Regression
A panic in the apiserver caused by the informer-sync health checker is now fixed. (#93600, @ialidzhikov) [SIG API Machinery]
Add kubectl wait --ignore-not-found flag (#90969, @zhouya0) [SIG CLI]
Adding fix to the statefulset controller to wait for pvc deletion before creating pods. (#93457, @ymmt2005) [SIG Apps]
Azure ARM client: don't segfault on empty response and http error (#94078, @bpineau) [SIG Cloud Provider]
Azure: fix a bug that kube-controller-manager would panic if wrong Azure VMSS name is configured (#94306, @knight42) [SIG Cloud Provider]
Azure: per VMSS VMSS VMs cache to prevent throttling on clusters having many attached VMSS (#93107, @bpineau) [SIG Cloud Provider]
Both apiserver_request_duration_seconds metrics and RequestReceivedTimestamp field of an audit event take
into account the time a request spends in the apiserver request filters. (#94903, @tkashem) [SIG API Machinery, Auth and Instrumentation]
Build/lib/release: Explicitly use '--platform' in building server images
When we switched to go-runner for building the apiserver,
controller-manager, and scheduler server components, we no longer
reference the individual architectures in the image names, specifically
in the 'FROM' directive of the server image Dockerfiles.
As a result, server images for non-amd64 images copy in the go-runner
amd64 binary instead of the go-runner that matches that architecture.
This commit explicitly sets the '--platform=linux/${arch}' to ensure
we're pulling the correct go-runner arch from the manifest list.
Before:
FROM ${base_image}
After:
FROM --platform=linux/${arch} ${base_image} (#94552, @justaugustus) [SIG Release]
CSIDriver object can be deployed during volume attachment. (#93710, @Jiawei0227) [SIG Apps, Node, Storage and Testing]
Do not add nodes labeled with kubernetes.azure.com/managed=false to backend pool of load balancer. (#93034, @matthias50) [SIG Cloud Provider]
Do not fail sorting empty elements. (#94666, @soltysh) [SIG CLI]
Do not retry volume expansion if CSI driver returns FailedPrecondition error (#92986, @gnufied) [SIG Node and Storage]
Dockershim security: pod sandbox now always run with no-new-privileges and runtime/default seccomp profile
dockershim seccomp: custom profiles can now have smaller seccomp profiles when set at pod level (#90948, @pjbgf) [SIG Node]
Dual-stack: make nodeipam compatible with existing single-stack clusters when dual-stack feature gate become enabled by default (#90439, @SataQiu) [SIG API Machinery]
Endpoint controller requeues service after an endpoint deletion event occurs to confirm that deleted endpoints are undesired to mitigate the effects of an out of sync endpoint cache. (#93030, @swetharepakula) [SIG Apps and Network]
EndpointSlice controllers now return immediately if they encounter an error creating, updating, or deleting resources. (#93908, @robscott) [SIG Apps and Network]
EndpointSliceMirroring controller now copies labels from Endpoints to EndpointSlices. (#93442, @robscott) [SIG Apps and Network]
EndpointSliceMirroring controller now mirrors Endpoints that do not have a Service associated with them. (#94171, @robscott) [SIG Apps, Network and Testing]
Ensure backoff step is set to 1 for Azure armclient. (#94180, @feiskyer) [SIG Cloud Provider]
Ensure getPrimaryInterfaceID not panic when network interfaces for Azure VMSS are null (#94355, @feiskyer) [SIG Cloud Provider]
Eviction requests for pods that have a non-zero DeletionTimestamp will always succeed (#91342, @michaelgugino) [SIG Apps]
Extended DSR loadbalancer feature in winkernel kube-proxy to HNS versions 9.3-9.max, 10.2+ (#93080, @elweb9858) [SIG Network]
Fix a concurrent map writes error in kubelet (#93773, @knight42) [SIG Node]
Fix a regression where kubeadm bails out with a fatal error when an optional version command line argument is supplied to the "kubeadm upgrade plan" command (#94421, @rosti) [SIG Cluster Lifecycle]
Fix bug where loadbalancer deletion gets stuck because of missing resource group #75198 (#93962, @phiphi282) [SIG Cloud Provider]
Fix calling AttachDisk on a previously attached EBS volume (#93567, @gnufied) [SIG Cloud Provider, Storage and Testing]
Fix detection of image filesystem, disk metrics for devicemapper, detection of OOM Kills on 5.0+ linux kernels. (#92919, @dashpole) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node]
Fix etcd_object_counts metric reported by kube-apiserver (#94773, @tkashem) [SIG API Machinery]
Fix incorrectly reported verbs for kube-apiserver metrics for CRD objects (#93523, @wojtek-t) [SIG API Machinery and Instrumentation]
Fix instance not found issues when an Azure Node is recreated in a short time (#93316, @feiskyer) [SIG Cloud Provider]
Fix kube-apiserver /readyz to contain "informer-sync" check ensuring that internal informers are synced. (#93670, @wojtek-t) [SIG API Machinery and Testing]
Fix kubectl SchemaError on CRDs with schema using x-kubernetes-preserve-unknown-fields on array types. (#94888, @sttts) [SIG API Machinery]
Fix memory leak in EndpointSliceTracker for EndpointSliceMirroring controller. (#93441, @robscott) [SIG Apps and Network]
Fix missing csi annotations on node during parallel csinode update. (#94389, @pacoxu) [SIG Storage]
Fix the cloudprovider_azure_api_request_duration_seconds metric buckets to correctly capture the latency metrics. Previously, the majority of the calls would fall in the "+Inf" bucket. (#94873, @marwanad) [SIG Cloud Provider and Instrumentation]
Fix: azure disk resize error if source does not exist (#93011, @andyzhangx) [SIG Cloud Provider]
Fix: detach azure disk broken on Azure Stack (#94885, @andyzhangx) [SIG Cloud Provider]
Fix: determine the correct ip config based on ip family (#93043, @aramase) [SIG Cloud Provider]
Fix: initial delay in mounting azure disk & file (#93052, @andyzhangx) [SIG Cloud Provider and Storage]
Fix: use sensitiveOptions on Windows mount (#94126, @andyzhangx) [SIG Cloud Provider and Storage]
Fixed Ceph RBD volume expansion when no ceph.conf exists (#92027, @juliantaylor) [SIG Storage]
Fixed a bug where improper storage and comparison of endpoints led to excessive API traffic from the endpoints controller (#94112, @damemi) [SIG Apps, Network and Testing]
Fixed a bug whereby the allocation of reusable CPUs and devices was not being honored when the TopologyManager was enabled (#93189, @klueska) [SIG Node]
Fixed a panic in kubectl debug when pod has multiple init containers or ephemeral containers (#94580, @kiyoshim55) [SIG CLI]
Fixed a regression that sometimes prevented kubectl portforward to work when TCP and UDP services were configured on the same port (#94728, @amorenoz) [SIG CLI]
Fixed bug in reflector that couldn't recover from "Too large resource version" errors with API servers 1.17.0-1.18.5 (#94316, @janeczku) [SIG API Machinery]
Fixed bug where kubectl top pod output is not sorted when --sort-by and --containers flags are used together (#93692, @brianpursley) [SIG CLI]
Fixed kubelet creating extra sandbox for pods with RestartPolicyOnFailure after all containers succeeded (#92614, @tnqn) [SIG Node and Testing]
Fixed memory leak in endpointSliceTracker (#92838, @tnqn) [SIG Apps and Network]
Fixed node data lost in kube-scheduler for clusters with imbalance on number of nodes across zones (#93355, @maelk) [SIG Scheduling]
Fixed the EndpointSliceController to correctly create endpoints for IPv6-only pods.
Fixed the EndpointController to allow IPv6 headless services, if the IPv6DualStack
feature gate is enabled, by specifying ipFamily: IPv6 on the service. (This already
worked with the EndpointSliceController.) (#91399, @danwinship) [SIG Apps and Network]
Fixes a bug evicting pods after a taint with a limited tolerationSeconds toleration is removed from a node (#93722, @liggitt) [SIG Apps and Node]
Fixes a bug where EndpointSlices would not be recreated after rapid Service recreation. (#94730, @robscott) [SIG Apps, Network and Testing]
Fixes a race condition in kubelet pod handling (#94751, @auxten) [SIG Node]
Fixes an issue proxying to ipv6 pods without specifying a port (#94834, @liggitt) [SIG API Machinery and Network]
Fixes an issue that can result in namespaced custom resources being orphaned when their namespace is deleted, if the CRD defining the custom resource is removed concurrently with namespaces being deleted, then recreated. (#93790, @liggitt) [SIG API Machinery and Apps]
Ignore root user check when windows pod starts (#92355, @wawa0210) [SIG Node and Windows]
Increased maximum IOPS of AWS EBS io1 volumes to 64,000 (current AWS maximum). (#90014, @jacobmarble) [SIG Cloud Provider and Storage]
K8s.io/apimachinery: runtime.DefaultUnstructuredConverter.FromUnstructured now handles converting integer fields to typed float values (#93250, @liggitt) [SIG API Machinery]
Kube-aggregator certificates are dynamically loaded on change from disk (#92791, @p0lyn0mial) [SIG API Machinery]
Kube-apiserver: fixed a bug returning inconsistent results from list requests which set a field or label selector and set a paging limit (#94002, @wojtek-t) [SIG API Machinery]
Kube-apiserver: jsonpath expressions with consecutive recursive descent operators are no longer evaluated for custom resource printer columns (#93408, @joelsmith) [SIG API Machinery]
Kube-proxy now trims extra spaces found in loadBalancerSourceRanges to match Service validation. (#94107, @robscott) [SIG Network]
Kube-up now includes CoreDNS version v1.7.0. Some of the major changes include:
Fixed a bug that could cause CoreDNS to stop updating service records.
Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set.
Remove already deprecated options resyncperiod and upstream in the Kubernetes plugin.
Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names.
Kubeadm now makes sure the etcd manifest is regenerated upon upgrade even when no etcd version change takes place (#94395, @rosti) [SIG Cluster Lifecycle]
Kubeadm: avoid a panic when determining if the running version of CoreDNS is supported during upgrades (#94299, @zouyee) [SIG Cluster Lifecycle]
Kubeadm: ensure "kubeadm reset" does not unmount the root "/var/lib/kubelet" directory if it is mounted by the user (#93702, @thtanaka) [SIG Cluster Lifecycle]
Kubeadm: ensure the etcd data directory is created with 0700 permissions during control-plane init and join (#94102, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: fix the bug that kubeadm tries to call 'docker info' even if the CRI socket was for another CR (#94555, @SataQiu) [SIG Cluster Lifecycle]
Kubeadm: relax the validation of kubeconfig server URLs. Allow the user to define custom kubeconfig server URLs without erroring out during validation of existing kubeconfig files (e.g. when using external CA mode). (#94816, @neolit123) [SIG Cluster Lifecycle]
Kubeadm: remove duplicate DNS names and IP addresses from generated certificates (#92753, @QianChenglong) [SIG Cluster Lifecycle]
Kubelet: assume that swap is disabled when /proc/swaps does not exist (#93931, @SataQiu) [SIG Node]
Kubelet: fix race condition in pluginWatcher (#93622, @knight42) [SIG Node]
Kuberuntime security: pod sandbox now always runs with runtime/default seccomp profile
kuberuntime seccomp: custom profiles can now have smaller seccomp profiles when set at pod level (#90949, @pjbgf) [SIG Node]
New Azure instance types do now have correct max data disk count information. (#94340, @ialidzhikov) [SIG Cloud Provider and Storage]
Pods with invalid Affinity/AntiAffinity LabelSelectors will now fail scheduling when these plugins are enabled (#93660, @damemi) [SIG Scheduling]
Require feature flag CustomCPUCFSQuotaPeriod if setting a non-default cpuCFSQuotaPeriod in kubelet config. (#94687, @karan) [SIG Node]
Reverted devicemanager for Windows node added in 1.19rc1. (#93263, @liggitt) [SIG Node and Windows]
Scheduler bugfix: Scheduler doesn't lose pod information when nodes are quickly recreated. This could happen when nodes are restarted or quickly recreated reusing a nodename. (#93938, @alculquicondor) [SIG Scalability, Scheduling and Testing]
The EndpointSlice controller now waits for EndpointSlice and Node caches to be synced before starting. (#94086, @robscott) [SIG Apps and Network]
The /debug/api_priority_and_fairness/dump_requests path at an apiserver will no longer return a phantom line for each exempt priority level. (#93406, @MikeSpreitzer) [SIG API Machinery]
The kubelet recognizes the --containerd-namespace flag to configure the namespace used by cadvisor. (#87054, @changyaowei) [SIG Node]
The terminationGracePeriodSeconds from pod spec is respected for the mirror pod. (#92442, @tedyu) [SIG Node and Testing]
Update Calico to v3.15.2 (#94241, @lmm) [SIG Cloud Provider]
Update default etcd server version to 3.4.13 (#94287, @jingyih) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing]
Updated Cluster Autoscaler to 1.19.0; (#93577, @vivekbagade) [SIG Autoscaling and Cloud Provider]
Use NLB Subnet CIDRs instead of VPC CIDRs in Health Check SG Rules (#93515, @t0rr3sp3dr0) [SIG Cloud Provider]
Users will see increase in time for deletion of pods and also guarantee that removal of pod from api server would mean deletion of all the resources from container runtime. (#92817, @kmala) [SIG Node]
Very large patches may now be specified to kubectl patch with the --patch-file flag instead of including them directly on the command line. The --patch and --patch-file flags are mutually exclusive. (#93548, @smarterclayton) [SIG CLI]
When creating a networking.k8s.io/v1 Ingress API object, spec.rules[*].http values are now validated consistently when the host field contains a wildcard. (#93954, @Miciah) [SIG CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Storage and Testing]
Other (Cleanup or Flake)
--cache-dir sets cache directory for both http and discovery, defaults to $HOME/.kube/cache (#92910, @soltysh) [SIG API Machinery and CLI]
Adds a bootstrapping ClusterRole, ClusterRoleBinding and group for /metrics, /livez/, /readyz/, & /healthz/- endpoints. (#93311, @logicalhan) [SIG API Machinery, Auth, Cloud Provider and Instrumentation]
Base-images: Update to debian-iptables:buster-v1.3.0
Uses iptables 1.8.5
base-images: Update to debian-base:buster-v1.2.0
cluster/images/etcd: Build etcd:3.4.13-1 image
Uses debian-base:buster-v1.2.0 (#94733, @justaugustus) [SIG API Machinery, Release and Testing]
Build: Update to go-runner:buster-v2.0.0 (#94167, @justaugustus) [SIG Release]
Fix kubelet to properly log when a container is started. Before, sometimes the log said that a container is dead and was restarted when it was started for the first time. This only happened when using pods with initContainers and regular containers. (#91469, @rata) [SIG Node]
Fix: license issue in blob disk feature (#92824, @andyzhangx) [SIG Cloud Provider]
Fixes the flooding warning messages about setting volume ownership for configmap/secret volumes (#92878, @jvanz) [SIG Instrumentation, Node and Storage]
Fixes the message about no auth for metrics in scheduler. (#94035, @zhouya0) [SIG Scheduling]
Kube-up: defaults to limiting critical pods to the kube-system namespace to match behavior prior to 1.17 (#93121, @liggitt) [SIG Cloud Provider and Scheduling]
Kubeadm: Separate argument key/value in log msg (#94016, @mrueg) [SIG Cluster Lifecycle]
Kubeadm: remove support for the "ci/k8s-master" version label. This label has been removed in the Kubernetes CI release process and would no longer work in kubeadm. You can use the "ci/latest" version label instead. See kubernetes/test-infra#18517 (#93626, @vikkyomkar) [SIG Cluster Lifecycle]
Kubeadm: remove the CoreDNS check for known image digests when applying the addon (#94506, @neolit123) [SIG Cluster Lifecycle]
Kubernetes is now built with go1.15.0 (#93939, @justaugustus) [SIG Release and Testing]
Kubernetes is now built with go1.15.0-rc.2 (#93827, @justaugustus) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node, Release and Testing]
Lock ExternalPolicyForExternalIP to default, this feature gate will be removed in 1.22. (#94581, @knabben) [SIG Network]
Service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset is removed. All Standard load balancers will always enable tcp resets. (#94297, @MarcPow) [SIG Cloud Provider]
Stop propagating SelfLink (deprecated in 1.16) in kube-apiserver (#94397, @wojtek-t) [SIG API Machinery and Testing]
Strip unnecessary security contexts on Windows (#93475, @ravisantoshgudimetla) [SIG Node, Testing and Windows]
To ensure the code be strong, add unit test for GetAddressAndDialer (#93180, @FreeZhang61) [SIG Node]
Update CNI plugins to v0.8.7 (#94367, @justaugustus) [SIG Cloud Provider, Network, Node, Release and Testing]
Update Golang to v1.14.5
Update repo-infra to 0.0.7 (to support go1.14.5 and go1.13.13)
Update default etcd server version to 3.4.9 (#92349, @jingyih) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing]
Update etcd client side to v3.4.13 (#94259, @jingyih) [SIG API Machinery and Cloud Provider]
kubectl get ingress now prefers the networking.k8s.io/v1 over extensions/v1beta1 (deprecated since v1.14). To explicitly request the deprecated version, use kubectl get ingress.v1beta1.extensions. (#94309, @liggitt) [SIG API Machinery and CLI]
고가용성(HA) 클러스터에서 최신 및 가장 오래된 kube-apiserver 인스턴스가 각각 한 단계 마이너 버전 내에 있어야 한다.
예:
최신 kube-apiserver는 1.24 이다.
다른 kube-apiserver 인스턴스는 1.24 및 1.23 을 지원한다.
kubelet
kubelet은 kube-apiserver보다 최신일 수 없으며, 2단계의 낮은 마이너 버전까지 지원한다.
예:
kube-apiserver가 1.24 이다.
kubelet은 1.24, 1.23 및 1.22 을 지원한다.
참고: HA 클러스터의 kube-apiserver 인스턴스 사이에 버전 차이가 있으면 허용되는 kubelet 버전의 범위도 줄어든다.
예:
kube-apiserver 인스턴스는 1.24 및 1.23 이다.
kubelet은 1.23 및 1.22 을 지원한다(1.24 는 kube-apiserver의 1.23 인스턴스보다 최신 버전이기 때문에 지원하지 않는다).
kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager
kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager는 그들과 통신하는 kube-apiserver 인스턴스보다 최신 버전이면 안 된다. kube-apiserver 마이너 버전과 일치할 것으로 예상하지만, 최대 한 단계 낮은 마이너 버전까지는 허용한다(실시간 업그레이드를 지원하기 위해서).
예:
kube-apiserver은 1.24 이다.
kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager는 1.24 과 1.23 을 지원한다.
참고: HA 클러스터의 kube-apiserver 인스턴스 간에 버전 차이가 존재하고 이러한 구성 요소가 클러스터의 모든 kube-apiserver 인스턴스와 통신할 수 있는 경우(예를 들어, 로드 밸런서를 통해서)에는 구성 요소의 허용하는 버전의 범위도 줄어든다.
예:
kube-apiserver 인스턴스는 1.24 및 1.23 이다.
kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager는 모든 kube-apiserver 인스턴스로 라우팅하는 로드 밸런서와 통신한다.
kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager는 1.23 에서 지원한다(1.24 는 kube-apiserver 인스턴스의 1.23 버전보다 최신이기 때문에 지원하지 않는다).
kubectl
kubectl은 kube-apiserver의 한 단계 마이너 버전(이전 또는 최신) 내에서 지원한다.
예:
kube-apiserver은 1.24 이다.
kubectl은 1.25, 1.24 및 1.23 을 지원한다.
참고: HA 클러스터의 kube-apiserver 인스턴스 간에 버전 차이가 있으면 지원되는 kubectl 버전의 범위도 줄어든다.
예:
kube-apiserver 인스턴스는 1.24 및 1.23 이다.
kubectl은 1.24 및 1.23 에서 지원한다(다른 버전은 kube-apiserver 인스턴스 중에 한 단계 이상의 마이너 버전 차이가 난다).
지원되는 구성 요소 업그레이드 순서
구성요소 간 지원되는 버전 차이는 구성요소를 업그레이드하는 순서에 영향을 준다.
이 섹션에서는 기존 클러스터를 버전 1.23 에서 버전 1.24 로 전환하기 위해 구성 요소를 업그레이드하는 순서를 설명한다.
kube-apiserver
사전 요구 사항:
단일 인스턴스 클러스터에서 기존 kube-apiserver 인스턴스는 1.23 이어야 한다.
HA 클러스터에서 모든 kube-apiserver 인스턴스는 1.23 또는 1.24 이어야 한다(이것은 kube-apiserver 인스턴스 간의 가장 최신과 오래된 버전의 차이를 최대 1개의 마이너 버전의 차이로 보장한다).
이 서버와 통신하는 kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager의 버전은 1.23 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니고 새로운 API서버 버전의 마이너 1개의 버전 내에 있음을 보장한다).
모든 kubelet 인스턴스는 버전 1.23 또는 1.22 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니며, 새로운 API서버 버전의 2개의 마이너 버전 내에 있음을 보장한다).
등록된 어드미션 웹훅은 새로운 kube-apiserver 인스턴스가 전송하는 데이터를 처리할 수 있다:
ValidatingWebhookConfiguration 그리고 MutatingWebhookConfiguration 오브젝트는 1.24 에 추가된 REST 리소스의 새 버전을 포함하도록 업데이트한다(또는 v1.15 이상에서 사용 가능한 matchPolicy: Equivalent option 설정을 사용).
웹훅은 자신에게 전송될 REST리소스의 새버전과 1.24 에서 기존 버전에 추가된 새로운 필드를 처리할 수 있다.
kube-apiserver를 1.24 으로 업그레이드
참고:API 지원 중단 및
API 변경 가이드라인
에 대한 프로젝트 정책에서는 단일 클러스터일지라도 업그레이드할 때 kube-apiserver의 마이너 버전을 건너뛰지 않도록 요구한다.
kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager
사전 요구 사항:
kube-apiserver 인스턴스는 1.24 이여야 한다(HA 클러스터에서 kube-apiserver 인스턴스와 통신할 수 있는 구성 요소를 업그레이드 전에 모든 kube-apiserver 인스턴스는 업그레이드되어야 한다).
kube-controller-manager, kube-scheduler 및 cloud-controller-manager 를 1.24 으로 업그레이드한다.
kubelet
사전 요구 사항:
kubelet과 통신하는 kube-apiserver 인스턴스는 1.24 이어야 한다.
필요에 따라서 kubelet 인스턴스를 1.24 으로 업그레이드할 수 있다(또는 1.23 아니면 1.22 으로 유지할 수 있음).
참고:kubelet 마이너 버전 업그레이드를 수행하기 전에, 해당 노드의 파드를 드레인(drain)해야 한다.
인플레이스(In-place) 마이너 버전 kubelet 업그레이드는 지원되지 않는다.
경고:
클러스터 안의 kubelet 인스턴스를 kube-apiserver의 버전보다 2단계 낮은 버전으로 실행하는 것을 권장하지 않는다:
kube-apiserver를 업그레이드한다면 한 단계 낮은 버전으로 업그레이드해야 한다.
이것은 관리되고 있는 3단계의 마이너 버전보다 낮은 kubelet을 실행할 가능성을 높인다.
kube-proxy
kube-proxy는 반드시 kubelet과 동일한 마이너 버전이어야 한다.
kube-proxy는 반드시 kube-apiserver 보다 최신 버전이면 안 된다.
kube-proxy는 kube-apiserver 보다 2단계 낮은 마이너 버전 이내여야 한다.
예:
kube-proxy 버전이 1.22 인 경우:
kubelet 버전도 반드시 1.22 와 동일한 마이너 버전이어야 한다.
kube-apiserver 버전은 반드시 1.22 에서 1.24 사이 이어야 한다.
2.2 - 학습 환경
kind
kind를 사용하면 로컬 컴퓨터에서
쿠버네티스를 사용할 수 있다. 이 툴을 사용하려면
도커를 설치 및 구성해야 한다.
kind 빠른 시작 페이지에는
kind를 시작하고 실행하기 위해 해야 할 일이 나와 있다.
minikube
kind와 마찬가지로, minikube는 로컬에서 쿠버네티스를 실행할 수 있는 툴이다.
minikube는 개인용 컴퓨터(윈도우, 맥OS, 리눅스 포함)에서
단일 노드 쿠버네티스 클러스터를 실행하므로
쿠버네티스를 시험해 보거나 일상적인 개발 작업에 사용할 수 있다.
리눅스 배포판의 init 시스템이 systemd인
경우, init 프로세스는 root control group(cgroup)을
생성 및 사용하는 cgroup 관리자로 작동한다.
Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다.
컨테이너 런타임과 kubelet이 cgroupfs를 사용하도록 설정할 수 있다. systemd와 함께
cgroupfs를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다.
단일 cgroup 관리자는 할당되는 리소스가 무엇인지를 단순화하고,
기본적으로 사용할 수 있는 리소스와 사용 중인 리소스를 일관성있게 볼 수 있다.
시스템에 두 개의 cgroup 관리자가 있으면, 이런 리소스도 두 개의 관점에서 보게 된다.
현장에서 사람들은 kubelet과 도커에 cgroupfs를 사용하고,
나머지 프로세스는 systemd를 사용하도록 노드가 설정된 경우, 리소스가 부족할 때
불안정해지는 사례를 보고했다.
컨테이너 런타임과 kubelet이 systemd를 cgroup 드라이버로 사용하도록 설정을 변경하면
시스템이 안정화된다. 도커에 대해 구성하려면, native.cgroupdriver=systemd를 설정한다.
주의:
클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 강력하게 권장하지 않는다.
하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면,
컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 파드 샌드박스 재생성을 시도할 때, 에러가 발생할 수 있다.
kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
자동화가 가능하다면, 업데이트된 구성을 사용하여 노드를 다른 노드로
교체하거나, 자동화를 사용하여 다시 설치한다.
컨테이너 런타임
주의:
이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.
containerd
이 섹션에는 containerd 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
필수 구성 요소를 설치 및 구성한다.
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# 필요한 sysctl 파라미터를 설정하면 재부팅 후에도 유지된다.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF# 재부팅하지 않고 sysctl 파라미터 적용
sudo sysctl --system
2. 추출과 설정
```powershell
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding ascii
# 설정을 검토한다. 설정에 따라 다음을 조정할 수 있다.
# - sandbox_image (쿠버네티스 일시중지 이미지)
# - cni bin 폴더와 conf 폴더 위치
Get-Content config.toml
# (선택사항 - 그러나 적극 권장함) Windows 디펜더 검사에서 containerd 제외
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 OS 를
아래의 표에서 적절한 필드로 설정한다.
운영 체제
$OS
Debian Unstable
Debian_Unstable
Debian Testing
Debian_Testing
그런 다음, $VERSION 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, VERSION=1.20 로 설정한다.
사용자의 설치를 특정 릴리스에 고정할 수 있다.
버전 1.20.0을 설치하려면, VERSION=1.20:1.20.0 을 설정한다.
다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 OS 를 아래의 표에서 적절한 필드로 설정한다.
운영 체제
$OS
Ubuntu 20.04
xUbuntu_20.04
Ubuntu 19.10
xUbuntu_19.10
Ubuntu 19.04
xUbuntu_19.04
Ubuntu 18.04
xUbuntu_18.04
그런 다음, $VERSION 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, VERSION=1.20 로 설정한다.
사용자의 설치를 특정 릴리스에 고정할 수 있다.
버전 1.20.0을 설치하려면, VERSION=1.20:1.20.0 을 설정한다.
다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 OS 를 아래의 표에서 적절한 필드로 설정한다.
운영 체제
$OS
Centos 8
CentOS_8
Centos 8 Stream
CentOS_8_Stream
Centos 7
CentOS_7
그런 다음, $VERSION 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, VERSION=1.20 로 설정한다.
사용자의 설치를 특정 릴리스에 고정할 수 있다.
버전 1.20.0을 설치하려면, VERSION=1.20:1.20.0 을 설정한다.
CRI-O는 기본적으로 systemd cgroup 드라이버를 사용한다. cgroupfs cgroup 드라이버로
전환하려면, /etc/crio/crio.conf 를 수정하거나 /etc/crio/crio.conf.d/02-cgroup-manager.conf 에
드롭-인(drop-in) 구성을 배치한다. 예를 들면, 다음과 같다.
기본적으로, 쿠버네티스는
컨테이너 런타임 인터페이스(CRI)를
사용하여 사용자가 선택한 컨테이너 런타임과 인터페이스한다.
런타임을 지정하지 않으면, kubeadm은 잘 알려진 유닉스 도메인 소켓 목록을 검색하여
설치된 컨테이너 런타임을 자동으로 감지하려고 한다.
다음 표에는 컨테이너 런타임 및 관련 소켓 경로가 나열되어 있다.
컨테이너 런타임과 소켓 경로
런타임
유닉스 도메인 소켓 경로
도커
/var/run/dockershim.sock
containerd
/run/containerd/containerd.sock
CRI-O
/var/run/crio/crio.sock
도커와 containerd가 모두 감지되면 도커가 우선시된다. 이것이 필요한 이유는 도커 18.09에서
도커만 설치한 경우에도 containerd와 함께 제공되므로 둘 다 감지될 수 있기
때문이다.
다른 두 개 이상의 런타임이 감지되면, kubeadm은 오류와 함께 종료된다.
kubelet: 클러스터의 모든 머신에서 실행되는 파드와 컨테이너 시작과
같은 작업을 수행하는 컴포넌트이다.
kubectl: 클러스터와 통신하기 위한 커맨드 라인 유틸리티이다.
kubeadm은 kubelet 또는 kubectl 을 설치하거나 관리하지 않으므로, kubeadm이
설치하려는 쿠버네티스 컨트롤 플레인의 버전과 일치하는지
확인해야 한다. 그렇지 않으면, 예상치 못한 버그 동작으로 이어질 수 있는
버전 차이(skew)가 발생할 위험이 있다. 그러나, kubelet과 컨트롤 플레인 사이에 하나의
마이너 버전 차이가 지원되지만, kubelet 버전은 API 서버 버전 보다
높을 수 없다. 예를 들어, 1.7.0 버전의 kubelet은 1.8.0 API 서버와 완전히 호환되어야 하지만,
그 반대의 경우는 아니다.
setenforce 0 및 sed ... 를 실행하여 permissive 모드로 SELinux를 설정하면 효과적으로 비활성화된다.
컨테이너가 호스트 파일시스템(예를 들어, 파드 네트워크에 필요한)에 접근하도록 허용하는 데 필요하다.
kubelet에서 SELinux 지원이 개선될 때까지 이 작업을 수행해야 한다.
구성 방법을 알고 있는 경우 SELinux를 활성화된 상태로 둘 수 있지만 kubeadm에서 지원하지 않는 설정이 필요할 수 있다.
CRICTL_VERSION="v1.17.0"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
kubeadm, kubelet, kubectl 설치 및 kubelet systemd 서비스 추가
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"cd$DOWNLOAD_DIR
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
sudo chmod +x {kubeadm,kubelet,kubectl}RELEASE_VERSION="v0.4.0"
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
sudo mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
kubelet 활성화 및 시작
systemctl enable --now kubelet
참고: Flatcar Container Linux 배포판은 /usr 디렉터리를 읽기 전용 파일시스템으로 마운트한다.
클러스터를 부트스트랩하기 전에, 쓰기 가능한 디렉터리를 구성하기 위한 추가 단계를 수행해야 한다.
쓰기 가능한 디렉터리를 설정하는 방법을 알아 보려면 Kubeadm 문제 해결 가이드를 참고한다.
kubelet은 이제 kubeadm이 수행할 작업을 알려 줄 때까지 크래시루프(crashloop) 상태로
기다려야 하므로 몇 초마다 다시 시작된다.
컨트롤 플레인 노드에서 kubelet이 사용하는 cgroup 드라이버 구성
도커를 사용할 때, kubeadm은 kubelet 용 cgroup 드라이버를 자동으로 감지하여
런타임 중에 /var/lib/kubelet/config.yaml 파일에 설정한다.
다른 CRI를 사용하는 경우, 다음과 같이 cgroupDriver 값을 kubeadm init 에 전달해야 한다.
cgroupfs 가 이미 kubelet의 기본값이기 때문에, 사용자의
CRI cgroup 드라이버가 cgroupfs 가 아닌 경우에만 위와 같이 설정해야 한다.
참고:--cgroup-driver 플래그가 kubelet에 의해 사용 중단되었으므로, /var/lib/kubelet/kubeadm-flags.env
또는 /etc/default/kubelet(RPM에 대해서는 /etc/sysconfig/kubelet)에 있는 경우, 그것을 제거하고 대신 KubeletConfiguration을
사용한다(기본적으로 /var/lib/kubelet/config.yaml 에 저장됨).
CRI-O 및 containerd와 같은 다른 컨테이너 런타임에 대한 cgroup 드라이버의
자동 감지에 대한 작업이 진행 중이다.
이 페이지는 고가용성(HA) 쿠버네티스 클러스터의 토플로지를 구성하는 두 가지 선택 사항을 설명한다.
다음과 같이 HA 클러스터를 구성할 수 있다.
etcd 노드와 컨트롤 플레인 노드를 함께 위치시키는 중첩된(stacked) 컨트롤 플레인 노드 방식
etcd와 컨트롤 플레인이 분리된 노드에서 운영되는 외부 etcd 노드 방식
HA 클러스터를 구성하기 전에 각 토플로지의 장단점을 주의 깊게 고려해야 한다.
참고: kubeadm은 etcd 클러스터를 정적으로 부트스트랩한다. 자세한 내용은 etcd 클러스터 구성 가이드
를 읽는다.
중첩된 etcd 토플로지
중첩된 HA 클러스터는 etcd에서 제공하는 분산 데이터 저장소 클러스터를,
컨트롤 플레인 구성 요소를 실행하는 kubeadm으로 관리되는 노드에 의해서 형성된 클러스터 상단에
중첩하는 토플로지이다.
각 컨트롤 플레인 노드는 kube-apiserver, kube-scheduler, kube-controller-manager 인스턴스를 운영한다.
kube-apiserver는 로드 밸런서를 이용하여 워커 노드에 노출되어 있다.
각 컨트롤 플레인 노드는 지역 etcd 맴버를 생성하고
이 etcd 맴버는 오직 해당 노드의 kube-apiserver와 통신한다.
비슷한 방식이 지역의 kube-controller-manager와 kube-scheduler에도 적용된다.
이 토플로지는 컨트롤 플레인과 etcd 맴버가 같은 노드에 묶여 있다.
이는 외부 etcd 노드의 클러스터를 구성하는 것보다는 단순하며 복제 관리도 간단하다.
그러나 중첩된 클러스터는 커플링에 실패할 위험이 있다. 한 노드가 다운되면 etcd 맴버와 컨트롤 플레인을 모두 잃어버리고,
중복성도 손상된다. 더 많은 컨트롤 플레인 노드를 추가하여 이 위험을 완화할 수 있다.
그러므로 HA 클러스터를 위해 최소 3개인 중첩된 컨트롤 플레인 노드를 운영해야 한다.
이는 kubeadm의 기본 토플로지이다. 지역 etcd 맴버는
kubeadm init와 kubeadm join --control-plane 을 이용할 때에 컨트롤 플레인 노드에 자동으로 생성된다.
외부 etcd 토플로지
외부 etcd를 이용하는 HA 클러스터는 etcd로 제공한 분산된 데이터 스토리지 클러스터가 컨트롤 플레인 구성 요소를 운영하는 노드로 형성하는 클러스터의 외부에 있는 토플로지이다.
중첩된 etcd 토플로지와 유사하게, 외부 etcd 토플로지에 각 컨트롤 플레인 노드는 kube-apiserver, kube-scheduler, kube-controller-manager의 인스턴스를 운영한다. 그리고 kube-apiserver는 로드 밸런서를 이용하여 워커노드에 노출한다. 그러나 etcd 맴버는 분리된 호스트에서 운영되고, 각 etcd 호스트는 각 컨트롤 플레인 노드의 kube-apiserver와 통신한다.
이 토플로지는 컨트롤 플레인과 etcd 맴버를 분리한다. 이는 그러므로
컨트롤 플레인 인스턴스나 etcd 맴버를 잃는 충격이 덜하고,
클러스터 중복성에 있어 중첩된 HA 토플로지만큼 영향을 미치지 않는다.
그러나, 이 토플로지는 중첩된 토플로지에 비해 호스트 개수가 두배나 필요하다.
이 토플로지로 HA 클러스터를 구성하기 위해서는 최소한 3개의 컨트롤 플레인과 3개의 etcd 노드가 필요하다.
kubeadm은 실험적으로 자체 호스팅 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록
해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을
통해 kubelet에 구성된 스태틱(static) 파드
대신 쿠버네티스 API를 통해 구성된 데몬셋(DaemonSet) 파드
로 실행된다.
kops는 클러스터 내부와 외부 모두에서 검색을 위해 DNS을 사용하기에 클라이언트에서 쿠버네티스 API 서버에 연결할
수 있다.
이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써
사용자는 클러스터를 헷갈리지 않을것이고, 동료들과 혼선없이 공유할 수 있으며,
IP를 기억할 필요없이 접근할 수 있다.
그렇게 하고 있겠지만, 클러스터를 구분하기 위해 서브도메인을 활용할 수 있다. 예를 들어
useast1.dev.example.com을 이용한다면, API 서버 엔드포인트는 api.useast1.dev.example.com가 될 것이다.
Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone은 useast1.dev.example.com,
dev.example.com 그리고 example.com 같은 것도 될 수 있다. kops는 이것들 모두와 잘 동작하며,
사용자는 보통 조직적인 부분을 고려해 결정한다(예를 들어, 사용자가 dev.example.com하위에 레코드를 생성하는것은 허용되지만,
example.com하위에는 그렇지 않을 수 있다).
dev.example.com을 hosted zone으로 사용하고 있다고 가정해보자.
보통 사용자는 일반적인 방법 에 따라 생성하거나
aws route53 create-hosted-zone --name dev.example.com --caller-reference 1 와 같은 커맨드를 이용한다.
그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는,
dev NS 레코드를 example.com에 생성한다. 만약 이것이 루트 도메인 네임이라면 이 NS 레코드들은
도메인 등록기관을 통해서 생성해야 한다(예를 들어, example.com는 example.com를 구매한 곳에서 설정 할 수 있다).
route53 도메인 설정을 확인한다(문제를 만드는 가장 큰 이유이다!). dig 툴을 실행해서
클러스터 설정이 정확한지 한번 더 확인한다.
dig NS dev.example.com
당신의 hosted zone용으로 할당된 3~4개의 NS 레코드를 Route53에서 확인할 수 있어야 한다.
(3/5) 클러스터 상태 저장용 S3 버킷 생성
kops는 설치 이후에도 클러스터를 관리할 수 있다. 이를 위해 사용자가 생성한 클러스터의 상태나
사용하는 키 정보들을 지속적으로 추적해야 한다. 이 정보가 S3에 저장된다.
이 버킷의 접근은 S3 권한으로 제어한다.
다수의 클러스터는 동일한 S3 버킷을 이용할 수 있고, 사용자는 이 S3 버킷을 같은 클러스트를
운영하는 동료에게 공유할 수 있다. 하지만 이 S3 버킷에 접근 가능한 사람은 사용자의
모든 클러스터에 관리자 접근이 가능하게 되니, 운영팀 이외로
공유되지 않도록 해야 한다.
그래서 보통 한 운영팀 당 하나의 S3 버킷을 가지도록 하기도 한다.(그리고 종종 운영팀
이름은 위에서 언급한 hosted zone과 동일하게 짓기도 한다!)
우리 예제에서는, dev.example.com를 hosted zone으로 했으니 clusters.dev.example.com를
S3 버킷 이름으로 정하자.
AWS_PROFILE를 선언한다. (AWS CLI 동작을 위해 다른 profile을 선택해야 할 경우)
aws s3 mb s3://clusters.dev.example.com를 이용해 S3 버킷을 생성한다.
export KOPS_STATE_STORE=s3://clusters.dev.example.com 하면, kops는 이 위치를 기본값으로 인식할 것이다.
이 부분을 bash profile등에 넣어두는것을 권장한다.
kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 설정
만을 생성한다는 것에 주의하자 - 이 부분은 다음 단계에서 kops update cluster 으로
구성해볼 것이다. 그 때 만들어진 설정을 점검하거나 변경할 수 있다.
인스턴스 그룹 수정: kops edit ig --name=useast1.dev.example.com nodes
마스터 인스턴스 그룹 수정: kops edit ig --name=useast1.dev.example.com master-us-east-1c
만약 kops사용이 처음이라면, 얼마 걸리지 않으니 이들을 시험해 본다. 인스턴스 그룹은
쿠버네티스 노드로 등록된 인스턴스의 집합을 말한다. AWS상에서는 auto-scaling-groups를
통해 만들어진다. 사용자는 여러 개의 인스턴스 그룹을 관리할 수 있는데,
예를 들어, spot과 on-demand 인스턴스 조합 또는 GPU 와 non-GPU 인스턴스의 조합으로 구성할 수 있다.
(5/5) AWS에 클러스터 생성
kops update cluster를 실행해 AWS에 클러스터를 생성한다.
kops update cluster useast1.dev.example.com --yes
실행은 수 초 만에 되지만, 실제로 클러스터가 준비되기 전까지 수 분이 걸릴 수 있다.
언제든 kops update cluster로 클러스터 설정을 변경할 수 있다. 사용자가
변경한 클러스터 설정을 그대로 반영해 줄 것이며, 필요다하면 AWS 나 쿠버네티스를 재설정 해 줄것이다.
예를 들면, kops edit ig nodes 뒤에 kops update cluster --yes를 실행해 설정을 반영한다.
그리고 kops rolling-update cluster로 설정을 즉시 원복시킬 수 있다.
--yes를 명시하지 않으면 kops update cluster 커맨드 후 어떤 설정이 변경될지가 표시된다.
운영계 클러스터 관리할 때 사용하기 좋다!
다른 애드온 탐험
애드온 리스트 에서 쿠버네티스 클러스터용 로깅, 모니터링, 네트워크 정책, 시각화 & 제어 등을 포함한 다른 애드온을 확인해본다.
정리하기
kops delete cluster useast1.dev.example.com --yes 로 클러스터를 삭제한다.
규모가 큰 디플로이먼트는 (100개 이상의 노드) 최적의 결과를 얻기 위해 특정한 조정을 필요로 할 수도 있다.
(5/5) 디플로이먼트 검증하기
Kubespray는 Netchecker를 사용하여 파드 사이의 연결성과 DNS 해석을 검증할 방법을 제공한다. Netchecker는 netchecker-agents 파드들이 DNS 요청을 해석하고 기본(default) 네임스페이스 내부에서 서로에게 ping을 보낼 수 있도록 보장한다. 그 파드들은 나머지 워크로드의 유사한 동작을 모방하고 클러스터의 상태 표시기 역할을 한다.
클러스터 동작
Kubespray는 클러스터를 관리하기 위한 추가적인 플레이북, scale 과 upgrade 를 제공한다.
클러스터 스케일링하기
scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "노드 추가하기" 문서를 확인하자. remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "노드 제거하기" 문서를 확인하자.
클러스터 업그레이드 하기
upgrade-cluster 플레이북을 실행해 클러스터를 업그레이드 할 수 있다. 더 자세히 알고 싶다면 "업그레이드" 문서를 확인하자.
클린업
reset 플레이북을 이용하여 노드들을 리셋하고 Kubespray로 설치된 모든 구성요소를 삭제할 수 있다.
주의: reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타겟으로 삼지 않도록 해야 한다!
윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 애플리케이션의 상당 부분을 구성한다. 윈도우 컨테이너는 프로세스와 패키지 종속성을 캡슐화하는 현대적인 방법을 제공하여, 데브옵스(DevOps) 사례를 더욱 쉽게 사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다. 쿠버네티스는 사실상의 표준 컨테이너 오케스트레이터가 되었으며, 쿠버네티스 1.14 릴리스에는 쿠버네티스 클러스터의 윈도우 노드에서 윈도우 컨테이너 스케줄링을 위한 프로덕션 지원이 포함되어 있어, 광범위한 윈도우 애플리케이션 생태계가 쿠버네티스의 강력한 기능을 활용할 수 있다. 윈도우 기반 애플리케이션과 리눅스 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 별도의 오케스트레이터를 찾을 필요가 없으므로, 운영 체제와 관계없이 배포 전반에 걸쳐 운영 효율성이 향상된다.
쿠버네티스의 윈도우 컨테이너
쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함한다. 쿠버네티스의 파드에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것과 유사하다.
윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 쿠버네티스 노드를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, 컨테이너 런타임 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 Microsoft 문서를 참고한다.
참고:마스터 컴포넌트를 포함한 쿠버네티스 컨트롤 플레인은 리눅스에서 계속 실행된다. 윈도우 전용 쿠버네티스 클러스터는 계획이 없다.
참고: 이 문서에서 윈도우 컨테이너에 대해 이야기할 때 프로세스 격리된 윈도우 컨테이너를 의미한다. Hyper-V 격리가 있는 윈도우 컨테이너는 향후 릴리스로 계획되어 있다.
지원되는 기능 및 제한
지원되는 기능
윈도우 OS 버전 지원
쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, 리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다.
쿠버네티스 버전
윈도우 서버 LTSC 릴리스
윈도우 서버 SAC 릴리스
Kubernetes v1.17
Windows Server 2019
Windows Server ver 1809
Kubernetes v1.18
Windows Server 2019
Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909
Kubernetes v1.19
Windows Server 2019
Windows Server ver 1909, Windows Server ver 2004
Kubernetes v1.20
Windows Server 2019
Windows Server ver 1909, Windows Server ver 2004
참고: 지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 윈도우 서버 서비스 채널에서 확인할 수 있다.
참고: 모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 버전-스큐(skew) 정책(노드 대 컨트롤 플레인 버전 관리)을 준수한다.
파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 이벤트가 윈도우 컨테이너에서 지원된다.
주의: ContainerD와 함께 GMSA를 사용하여 커널 패치가 필요한 윈도우 네트워크 공유에 액세스 할 때 알려진 제한이 있다. 이 제한을 해결하기위한 업데이트는 현재 Windows Server, 버전 2004에서 사용할 수 있으며 2021년 초에 Windows Server 2019에서 사용할 수 있다. Microsoft 윈도우 컨테이너 이슈 트래커에서 업데이트를 확인한다.
퍼시스턴트 스토리지(Persistent Storage)
쿠버네티스 볼륨을 사용하면 데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는 복잡한 애플리케이션을 쿠버네티스에 배포할 수 있다. 특정 스토리지 백엔드 또는 프로토콜과 관련된 퍼시스턴트 볼륨 관리에는 볼륨 프로비저닝/디-프로비저닝/크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 데이터를 유지해야 하는 파드의 개별 컨테이너에 볼륨 마운트/분리와 같은 작업이 포함된다. 특정 스토리지 백엔드 또는 프로토콜에 대해 이러한 볼륨 관리 작업을 구현하는 코드는 쿠버네티스 볼륨 플러그인의 형태로 제공된다. 다음과 같은 광범위한 쿠버네티스 볼륨 플러그인 클래스가 윈도우에서 지원된다.
인-트리(In-tree) 볼륨 플러그인
인-트리 볼륨 플러그인과 관련된 코드는 핵심 쿠버네티스 코드 베이스의 일부로 제공된다. 인-트리 볼륨 플러그인 배포는 추가 스크립트를 설치하거나 별도의 컨테이너화된 플러그인 컴포넌트를 배포할 필요가 없다. 이러한 플러그인들은 볼륨 프로비저닝/디-프로비저닝, 스토리지 백엔드 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리할 수 있다. 다음의 인-트리 플러그인은 윈도우 노드를 지원한다.
FlexVolume 플러그인과 관련된 코드는 아웃-오브-트리(out-of-tree) 스크립트 또는 호스트에 직접 배포해야 하는 바이너리로 제공된다. FlexVolume 플러그인은 쿠버네티스 노드에 볼륨 연결/분리 및 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리한다. FlexVolume 플러그인과 관련된 퍼시스턴트 볼륨의 프로비저닝/디-프로비저닝은 일반적으로 FlexVolume 플러그인과는 별도의 외부 프로비저너를 통해 처리될 수 있다. 호스트에서 powershell 스크립트로 배포된 다음의 FlexVolume 플러그인은 윈도우 노드를 지원한다.
CSI 플러그인과 관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) 및 스테이트풀셋(StatefulSets)과 같은 표준 쿠버네티스 구성을 사용하여 배포되는 아웃-오브-트리 스크립트 및 바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은 일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러 플러그인으로 구성된다.
CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된 퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은 다양한 특권이 필요한(privileged) 작업을 수행해야 한다. 이러한 작업은 호스트 운영 체제마다 다르다. 리눅스 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인은 일반적으로 특권을 가진 컨테이너로 배포된다. 윈도우 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에서 관리되고, 각 윈도우 노드에 사전 설치되어야 하는 독립형(stand-alone) 바이너리인 csi-proxy를 사용하여 지원된다. 자세한 내용은 배포하려는 CSI 플러그인의 배포 가이드를 참조한다.
네트워킹
윈도우 컨테이너용 네트워킹은 CNI 플러그인을 통해 노출된다. 윈도우 컨테이너는 네트워킹과 관련하여 가상 머신과 유사하게 작동한다. 각 컨테이너에는 Hyper-V 가상 스위치(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)가 있다. 호스트 네트워킹 서비스(HNS)와 호스트 컴퓨팅 서비스(HCS)는 함께 작동하여 컨테이너를 만들고 컨테이너 vNIC을 네트워크에 연결한다. HCS는 컨테이너 관리를 담당하는 반면 HNS는 다음과 같은 네트워킹 리소스 관리를 담당한다.
가상 네트워크(vSwitch 생성 포함)
엔드포인트 / vNIC
네임스페이스
정책(패킷 캡슐화, 로드 밸런싱 규칙, ACL, NAT 규칙 등)
다음의 서비스 사양 유형이 지원된다.
NodePort
ClusterIP
LoadBalancer
ExternalName
네트워크 모드
윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다. 윈도우와 리눅스 워커 노드가 있는 이기종 클러스터에서는 윈도우와 리눅스 모두에서 호환되는 네트워킹 솔루션을 선택해야 한다. 윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며 각 CNI 사용 시 권장 사항이 있다.
네트워크 드라이버
설명
컨테이너 패킷 수정
네트워크 플러그인
네트워크 플러그인 특성
L2bridge
컨테이너는 외부 vSwitch에 연결된다. 컨테이너는 언더레이 네트워크에 연결된다. 하지만 인그레스/이그레스시에 재작성되기 때문에 물리적 네트워크가 컨테이너 MAC을 학습할 필요가 없다.
MAC은 호스트 MAC에 다시 쓰여지고, IP는 HNS OutboundNAT 정책을 사용하여 호스트 IP에 다시 쓰여질 수 있다.
win-overlay는 가상 컨테이너 네트워크를 호스트의 언더레이에서 격리하려는 경우(예: 보안 상의 이유로) 사용해야 한다. 데이터 센터의 IP에 제한이 있는 경우, (다른 VNID 태그가 있는) 다른 오버레이 네트워크에 IP를 재사용할 수 있다. 이 옵션을 사용하려면 윈도우 서버 2019에서 KB4489899가 필요하다.
외부 vSwitch가 필요하다. 컨테이너는 논리적 네트워크(논리적 스위치 및 라우터)를 통해 파드 내 통신을 가능하게 하는 외부 vSwitch에 연결된다.
패킷은 GENEVE 또는 STT를 통해 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다. 패킷은 ovn 네트워크 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다. NAT는 north-south 통신(데이터 센터와 클라이언트, 네트워크 상의 데이터 센터 외부와의 통신)을 위해 수행된다.
위에서 설명한대로 플란넬(Flannel) CNI 메타 플러그인은 VXLAN 네트워크 백엔드(alpha 지원, win-overlay에 위임) 및 host-gateway network backend (안정적인 지원, win-bridge에 위임)를 통해 윈도우에서도 지원된다. 이 플러그인은 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) 중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 함께 집계한다. 이후 네트워크 연결을 위한 참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 구성을 IPAM 플러그인 (예: 호스트-로컬)으로 보낸다.
노드, 파드, 서비스 오브젝트의 경우 TCP/UDP 트래픽에 대해 다음 네트워크 흐름이 지원된다.
IPv6DualStack기능 게이트를 사용하여 l2bridge 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 IPv4/IPv6 이중 스택 활성화를 참조한다.
참고: 윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 (커널 버전 10.0.19041.610) 이상이 필요하다.
참고: 윈도우의 오버레이(VXLAN) 네트워크는 현재 이중 스택 네트워킹을 지원하지 않는다.
제한
윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다.
자원 관리
리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. 컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. 반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) 오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입 될(assert) 수 없으므로 권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 매니져(Security Account Manager, SAM)가 분리되어 있으므로 컨테이너는 호스트의 ID를 가정할 수 없다.
자원 예약
메모리 예약
윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다. 윈도우는 모든 사용자-모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일이 필수이다. 결과적으로 윈도우에서는 리눅스에서 발생할 수 있는 메모리 부족 상태에 도달하지 않으며, 프로세스는 메모리 부족 (out of memory, OOM) 종료를 겪는 대신 디스크로 페이징한다. 메모리가 오버프로비저닝되고 모든 물리 메모리가 고갈되면 페이징으로 인해 성능이 저하될 수 있다.
kubelet 파라미터 --kubelet-reserve 를 사용하여 메모리 사용량을 합리적인 범위 내로 유지할 수 있으며, --system-reserve 를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 노드 할당(NodeAllocatable)은 줄어든다.
참고: 워크로드를 배포할 때, 컨테이너에 리소스 제한을 사용한다 (제한만 설정하거나, 제한이 요청과 같아야 함). 이 또한 NodeAllocatable에서 차감되며, 메모리가 꽉 찬 노드에 스케줄러가 파드를 할당하지 않도록 제한한다.
오버프로비저닝을 방지하는 가장 좋은 방법은 윈도우, 도커, 그리고 쿠버네티스 프로세스를 위해 최소 2GB 이상의 시스템 예약 메모리로 kubelet을 설정하는 것이다.
CPU 예약
윈도우, 도커, 그리고 다른 쿠버네티스 호스트 프로세스가 이벤트에 잘 응답할 수 있도록, CPU의 일정 비율을 예약하는 것이 좋다. 이 값은 윈도우 노드에 있는 CPU 코어 수에 따라 조정해야 한다. 이 비율을 결정하려면, 각 노드의 최대 파드 밀도(density)를 관찰하고, 시스템 서비스의 CPU 사용량을 모니터링하여 워크로드 요구 사항을 충족하는 값을 선택해야 한다.
kubelet 파라미터 --kubelet-reserve 를 사용하여 CPU 사용량을 합리적인 범위 내로 유지할 수 있으며, --system-reserve 를 사용하여 노드(컨테이너 외부)의 CPU 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 노드 할당(NodeAllocatable)은 줄어든다.
기능 제한
TerminationGracePeriod: 구현되지 않음
단일 파일 매핑: CRI-ContainerD로 구현 예정
종료 메시지: CRI-ContainerD로 구현 예정
특권을 가진(Privileged) 컨테이너: 현재 윈도우 컨테이너에서 지원되지 않음
HugePages: 현재 윈도우 컨테이너에서 지원되지 않음
기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다.
공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 API 섹션 참조).
각 플래그의 리눅스와의 차이점
윈도우 노드에서의 kubelet 플래그는 아래와 같이 다르게 동작한다.
--kubelet-reserve, --system-reserve, --eviction-hard 플래그는 Node Allocatable 업데이트
--enforce-node-allocable을 사용한 축출(Eviction)은 구현되지 않았다.
--eviction-hard와 --eviction-soft를 사용한 축출은 구현되지 않았다.
MemoryPressure 조건은 구현되지 않았다.
kubelet이 취한 OOM 축출 조치가 없다.
윈도우 노드에서 실행되는 Kubelet에는 메모리 제한이 없다. --kubelet-reserve와 --system-reserve는 호스트에서 실행되는 kubelet 또는 프로세스에 제한을 설정하지 않는다. 이는 호스트의 kubelet 또는 프로세스가 node-allocatable 및 스케줄러 외부에서 메모리 리소스 부족을 유발할 수 있음을 의미한다.
kubelet 프로세스의 우선 순위를 설정하는 추가 플래그는 --windows-priorityclass라는 윈도우 노드에서 사용할 수 있다. 이 플래그를 사용하면 kubelet 프로세스가 윈도우 호스트에서 실행중인 다른 프로세스와 비교할 때 더 많은 CPU 시간 슬라이스을 얻을 수 있다. 허용되는 값과 그 의미에 대한 자세한 내용은 윈도우 우선순위 클래스에서 확인할 수 있다. kubelet이 항상 충분한 CPU주기를 갖도록 하려면 이 플래그를 ABOVE_NORMAL_PRIORITY_CLASS 이상으로 설정하는 것이 좋다.
스토리지
윈도우에는 컨테이너 계층을 마운트하고 NTFS를 기반으로 하는 복제 파일시스템을 만드는 레이어드(layered) 파일시스템 드라이버가 있다. 컨테이너의 모든 파일 경로는 해당 컨테이너의 컨텍스트 내에서만 확인된다.
도커 볼륨 마운트는 개별 파일이 아닌 컨테이너의 디렉토리 만 대상으로 할 수 있다. 이 제한은 CRI-containerD에는 존재하지 않는다.
볼륨 마운트는 파일이나 디렉터리를 호스트 파일시스템으로 다시 투영할 수 없다.
읽기 전용 파일시스템은 윈도우 레지스트리 및 SAM 데이터베이스에 항상 쓰기 접근이 필요하기 때문에 지원되지 않는다. 그러나 읽기 전용 볼륨은 지원된다.
볼륨 사용자 마스크(user-masks) 및 권한은 사용할 수 없다. SAM은 호스트와 컨테이너 간에 공유되지 않기 때문에 이들 간에 매핑이 없다. 모든 권한은 컨테이너 컨텍스트 내에서 해결된다.
결과적으로, 다음 스토리지 기능은 윈도우 노드에서 지원되지 않는다.
볼륨 하위 경로(subpath) 마운트. 전체 볼륨만 윈도우 컨테이너에 마운트할 수 있다.
윈도우 호스트 네트워킹 서비스와 가상 스위치는 네임스페이스를 구현하고 파드 또는 컨테이너에 필요한 가상 NIC을 만들 수 있다. 그러나 DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /etc/... 파일이 아닌 윈도우 레지스트리 데이터베이스에 저장된다. 컨테이너의 윈도우 레지스트리는 호스트 레지스트리와 별개이므로 호스트에서 컨테이너로 /etc/resolv.conf를 매핑하는 것과 같은 개념은 리눅스에서와 동일한 효과를 갖지 않는다. 해당 컨테이너의 컨텍스트에서 실행되는 윈도우 API를 사용하여 구성해야 한다. 따라서 CNI 구현에서는 파일 매핑에 의존하는 대신 HNS를 호출하여 네트워크 세부 정보를 파드 또는 컨테이너로 전달해야 한다.
다음 네트워킹 기능은 윈도우 노드에서 지원되지 않는다.
윈도우 파드에서는 호스트 네트워킹 모드를 사용할 수 없다.
노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 외부 클라이언트에서는 가능)
노드에서 서비스 VIP에 접근하는 것은 향후 윈도우 서버 릴리스에서 사용할 수 있다.
한 서비스는 최대 64개의 백엔드 파드 또는 고유한 목적지 IP를 지원할 수 있다.
kube-proxy의 오버레이 네트워킹 지원은 알파 릴리스이다. 또한 윈도우 서버 2019에 KB4482887을 설치해야 한다.
로컬 트래픽 정책 및 DSR 모드
l2bridge, l2tunnel 또는 오버레이 네트워크에 연결된 윈도우 컨테이너는 IPv6 스택을 통한 통신을 지원하지 않는다. 이러한 네트워크 드라이버가 IPv6 주소를 사용하고 kubelet, kube-proxy 및 CNI 플러그인에서 후속 쿠버네티스 작업을 사용할 수 있도록 하는데 필요한 뛰어난 윈도우 플랫폼 작업이 있다.
win-overlay, win-bridge, Azure-CNI 플러그인을 통해 ICMP 프로토콜을 사용하는 아웃바운드 통신. 특히, 윈도우 데이터 플레인(VFP)은 ICMP 패킷 치환을 지원하지 않는다. 이것은 다음을 의미한다.
동일한 네트워크(예: ping을 통한 파드 간 통신) 내의 목적지로 전달되는 ICMP 패킷은 예상대로 제한 없이 작동한다.
TCP/UDP 패킷은 예상대로 제한 없이 작동한다.
원격 네트워크를 통과하도록 지정된 ICMP 패킷(예: ping을 통한 파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로 소스로 다시 라우팅되지 않는다.
TCP/UDP 패킷은 여전히 치환될 수 있기 때문에 ping <destination>을 curl <destination>으로 대체하여 외부와의 연결을 디버깅할 수 있다.
해당 기능은 쿠버네티스 v1.15에 추가되었다.
kubectl port-forward
CNI 플러그인
윈도우 참조 네트워크 플러그인 win-bridge와 win-overlay는 현재 "CHECK" 구현 누락으로 인해 CNI 사양 v0.4.0을 구현하지 않는다.
Flannel VXLAN CNI는 윈도우에서 다음과 같은 제한이 있다.
노드-파드 연결은 설계상 불가능하다. Flannel v0.12.0(또는 그 이상)이 있는 로컬 파드에서만 가능하다.
VNI 4096와 UDP 4789 포트 사용은 제한된다. VNI 제한은 작업 중이며 향후 릴리스(오픈 소스 flannel 변경)에서 구현될 것이다. 이러한 파라미터에 대한 자세한 내용은 공식 Flannel VXLAN 백엔드 문서를 참고한다.
DNS
ClusterFirstWithHostNet은 DNS에서 지원되지 않는다. 윈도우는 '.'이 있는 모든 이름을 FQDN으로 처리하고 PQDN 확인을 건너뛴다.
리눅스에서는 PQDN을 확인하려고 할 때 사용되는 DNS 접미사 목록이 있다. 윈도우에서는 해당 파드의 네임스페이스(예: mydns.svc.cluster.local)와 연결된 DNS 접미사인 DNS 접미사 1개만 있다. 윈도우는 FQDN과 서비스 또는 해당 접미사만으로 확인할 수 있는 이름을 확인할 수 있다. 예를 들어, 디폴트 네임스페이스에서 생성된 파드에는 DNS 접미사 default.svc.cluster.local이 있다. 윈도우 파드에서는 kubernetes.default.svc.cluster.local 및 kubernetes를 모두 확인할 수 있지만 kubernetes.default 또는 kubernetes.default.svc와 같은 중간 항목은 확인할 수 없다.
윈도우에서는 사용할 수 있는 여러 가지의 DNS 리졸버(resolver)가 있다. 이들은 약간 다른 동작을 제공하므로, 이름 쿼리 확인을 위해 Resolve-DNSName 유틸리티를 사용하는 것이 좋다.
IPv6
윈도우의 쿠버네티스는 단일 스택 "IPv6 전용" 네트워킹을 지원하지 않는다. 그러나 단일 제품군 서비스를 사용하는 파드와 노드에 대한 이중 스택 IPv4/IPv6 네트워킹이 지원된다. 자세한 내용은 IPv4/IPv6 이중 스택 네트워킹을 참고한다.
세션 어피니티(affinity)
service.spec.sessionAffinityConfig.clientIP.timeoutSeconds를 사용하는 윈도우 서비스의 최대 세션 고정(sticky) 시간 설정은 지원되지 않는다.
보안
시크릿(Secret)은 노드의 볼륨(리눅스의 tmpfs/in-memory와 비교)에 일반 텍스트로 작성된다. 이는 고객이 두 가지 작업을 수행해야 함을 의미한다.
RunAsUsername은 컨테이너 프로세스를 노드 기본 사용자로 실행하기 위해 윈도우 파드 또는 컨테이너에 지정할 수 있다. 이것은 RunAsUser와 거의 동일하다.
SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다.
또한 이미 언급했듯이 특권을 가진 컨테이너는 윈도우에서 지원되지 않는다.
API
대부분의 Kubernetes API가 윈도우에서 작동하는 방식은 차이가 없다. 중요한 차이점은 OS와 컨테이너 런타임의 차이로 귀결된다. 특정 상황에서 파드 또는 컨테이너와 같은 워크로드 API의 일부 속성은 리눅스에서 구현되고 윈도우에서 실행되지 않는다는 가정 하에 설계되었다.
높은 수준에서 이러한 OS 개념은 다르다.
ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 /etc/groups 또는 /etc/passwd의 별칭일 뿐이다. 윈도우는 윈도우 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다.
파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 SID를 기반으로 하는 접근 제어 목록을 사용한다.
파일 경로 - 윈도우의 규칙은 / 대신 \를 사용하는 것이다. Go IO 라이브러리는 두 가지 파일 경로 분리자를 모두 허용한다. 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 \가 필요할 수 있다.
신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 하나 이상을 구현할 수 있다.
UI 스레드는 WM_CLOSE를 포함하여 잘 정의된(well-defined) 메시지를 처리한다.
콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다.
서비스는 SERVICE_CONTROL_STOP 제어 코드를 수용할 수 있는 Service Control Handler 함수를 등록한다.
종료 코드는 0일 때 성공, 0이 아닌 경우 실패인 동일한 규칙을 따른다. 특정 오류 코드는 윈도우와 리눅스에서 다를 수 있다. 그러나 쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달된 종료 코드는 변경되지 않는다.
V1.Container
V1.Container.ResourceRequirements.limits.cpu 및 V1.Container.ResourceRequirements.limits.memory - 윈도우는 CPU 할당에 하드 리밋(hard limit)을 사용하지 않는다. 대신 공유 시스템이 사용된다. 밀리코어를 기반으로 하는 기존 필드는 윈도우 스케줄러가 뒤따르는 상대적인 공유로 스케일된다. 참고: kuberuntime/helpers_windows.go, 참고: Microsoft 문서 내 리소스 제어
Huge page는 윈도우 컨테이너 런타임에서 구현되지 않으며, 사용할 수 없다. 컨테이너에 대해 구성할 수 없는 사용자 권한(privilege) 어설트가 필요하다.
V1.Container.ResourceRequirements.requests.cpu 및 V1.Container.ResourceRequirements.requests.memory - 노드의 사용 가능한 리소스에서 요청(requests)을 빼서, 노드에 대한 오버 프로비저닝을 방지하는데 사용할 수 있다. 그러나 오버 프로비저닝된 노드에서 리소스를 보장하는 데는 사용할 수 없다. 운영자가 오버 프로비저닝을 완전히 피하려는 경우 모범 사례로 모든 컨테이너에 적용해야 한다.
V1.Container.SecurityContext.allowPrivilegeEscalation - 윈도우에서는 불가능하며, 어떤 기능도 연결되지 않는다.
V1.Container.SecurityContext.Capabilities - POSIX 기능은 윈도우에서 구현되지 않는다.
V1.Container.SecurityContext.privileged - 윈도우는 특권을 가진 컨테이너를 지원하지 않는다.
V1.Container.SecurityContext.procMount - 윈도우에는 /proc 파일시스템이 없다.
V1.Container.SecurityContext.readOnlyRootFilesystem - 윈도우에서는 불가능하며, 레지스트리 및 시스템 프로세스가 컨테이너 내부에서 실행되려면 쓰기 권한이 필요하다.
V1.Container.SecurityContext.runAsGroup - 윈도우에서는 불가능하며, GID 지원이 없다.
V1.Container.SecurityContext.runAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티(identity)인 ContainerAdministrator이다.
V1.Container.SecurityContext.runAsUser - 윈도우에서는 불가능하며, 정수값으로의 UID 지원이 없다.
V1.Container.SecurityContext.seLinuxOptions - 윈도우에서는 불가능하며, SELinux가 없다.
V1.Container.terminationMessagePath - 윈도우가 단일 파일 매핑을 지원하지 않는다는 점에서 몇 가지 제한이 있다. 기본값은 /dev/termination-log이며, 기본적으로 윈도우에 존재하지 않기 때문에 작동한다.
V1.Pod
V1.Pod.hostIPC, v1.pod.hostpid - 윈도우에서 호스트 네임스페이스 공유가 불가능하다.
V1.Pod.hostNetwork - 호스트 네트워크를 공유하기 위한 윈도우 OS 지원이 없다.
V1.Pod.dnsPolicy - ClusterFirstWithHostNet - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에 지원되지 않는다.
V1.Pod.podSecurityContext - 아래 V1.PodSecurityContext 내용을 참고한다.
V1.Pod.shareProcessNamespace - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 리눅스 네임스페이스에 따라 다르다. 윈도우는 프로세스 네임스페이스 또는 컨테이너의 루트 파일시스템을 공유할 수 없다. 네트워크만 공유할 수 있다.
V1.Pod.terminationGracePeriodSeconds - 이것은 윈도우의 도커에서 완전히 구현되지 않았다. 참조의 내용을 참고한다. 현재 동작은 ENTRYPOINT 프로세스가 CTRL_SHUTDOWN_EVENT로 전송된 다음, 윈도우가 기본적으로 5초를 기다린 후, 마지막으로 정상적인 윈도우 종료 동작을 사용하여 모든 프로세스를 종료하는 것이다. 5초 기본값은 실제로 컨테이너 내부 윈도우 레지스트리에 있으므로 컨테이너를 빌드할 때 재정의 할 수 있다.
V1.Pod.volumeDevices - 이것은 베타 기능이며, 윈도우에서 구현되지 않는다. 윈도우는 원시 블록 장치(raw block device)를 파드에 연결할 수 없다.
V1.Pod.volumes - EmptyDir, 시크릿, 컨피그맵, HostPath - 모두 작동하며 TestGrid에 테스트가 있다.
V1.emptyDirVolumeSource - 노드 기본 매체는 윈도우의 디스크이다. 윈도우에는 내장 RAM 디스크가 없기 때문에 메모리는 지원되지 않는다.
V1.VolumeMount.mountPropagation - 마운트 전파(propagation)는 윈도우에서 지원되지 않는다.
V1.PodSecurityContext
PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 위해 여기에 나열한다.
V1.PodSecurityContext.SELinuxOptions - SELinux는 윈도우에서 사용할 수 없다.
V1.PodSecurityContext.RunAsUser - 윈도우에서는 사용할 수 없는 UID를 제공한다.
V1.PodSecurityContext.RunAsGroup - 윈도우에서는 사용할 수 없는 GID를 제공한다.
V1.PodSecurityContext.RunAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티인 ContainerAdministrator이다.
V1.PodSecurityContext.SupplementalGroups - 윈도우에서는 사용할 수 없는 GID를 제공한다.
V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 일부이다. 윈도우에는 이에 상응하는 것이 없다.
운영 체제 버전 제한
윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다.
도움 받기 및 트러블슈팅
쿠버네티스 클러스터 트러블슈팅을 위한 기본 도움말은 이 섹션에서 먼저 찾아야 한다. 이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. 로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 한다. SIG-Windows 로그 수집에 대한 기여 가이드의 지침을 따른다.
start.ps1이 성공적으로 완료되었는지 어떻게 알 수 있는가?
kubelet, kube-proxy 및 (Flannel을 네트워킹 솔루션으로 선택한 경우) 노드에서 실행 중인 flanneld 호스트 에이전트 프로세스를 확인할 수 있어야 하는데, 별도의 PowerShell 윈도우에서 실행 중인 로그가 표시된다. 또한 윈도우 노드는 쿠버네티스 클러스터에서 "Ready"로 조회되어야 한다.
백그라운드에서 서비스로 실행되도록 쿠버네티스 노드 프로세스를 구성할 수 있는가?
Kubelet 및 kube-proxy는 이미 기본 윈도우 서비스로 실행되도록 구성되어 있으며, 실패(예: 프로세스 충돌) 시 서비스를 자동으로 다시 시작하여 복원력(resiliency)을 제공한다. 이러한 노드 컴포넌트를 서비스로 구성하기 위한 두 가지 옵션이 있다.
네이티브 윈도우 서비스
Kubelet와 kube-proxy는 sc.exe를 사용하여 네이티브 윈도우 서비스로 실행될 수 있다.
# 두 개의 개별 명령으로 kubelet 및 kube-proxy에 대한 서비스 생성
sc.exe create <컴포넌트_명> binPath= "<바이너리_경로> --service <다른_인자>"# 인자에 공백이 포함된 경우 이스케이프 되어야 한다.
sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <다른_인자>"# 서비스 시작Start-Service kubelet
Start-Service kube-proxy
# 서비스 중지Stop-Service kubelet (-Force)
Stop-Service kube-proxy (-Force)
# 서비스 상태 질의Get-Service kubelet
Get-Service kube-proxy
nssm.exe 사용
또한 언제든지 nssm.exe와 같은 대체 서비스 관리자를 사용하여 백그라운드에서 이러한 프로세스(flanneld, kubelet, kube-proxy)를 실행할 수 있다. 이 샘플 스크립트를 사용하여 백그라운드에서 윈도우 서비스로 실행하기 위해 nssm.exe를 활용하여 kubelet, kube-proxy, flanneld.exe를 등록할 수 있다.
register-svc.ps1 -NetworkMode <네트워크 모드> -ManagementIP <윈도우 노드 IP> -ClusterCIDR <클러스터 서브넷> -KubeDnsServiceIP <Kube-dns 서비스 IP> -LogDir <로그 위치 디렉터리>
# NetworkMode = 네트워크 모드 l2bridge(flannel host-gw, 기본값이기도 함) 또는 네트워크 솔루션으로 선택한 오버레이(flannel vxlan)# ManagementIP = 윈도우 노드에 할당된 IP 주소. ipconfig를 사용하여 찾을 수 있다.# ClusterCIDR = 클러스터 서브넷 범위. (기본값 10.244.0.0/16)# KubeDnsServiceIP = 쿠버네티스 DNS 서비스 IP (기본값 10.96.0.10)# LogDir = kubelet 및 kube-proxy 로그가 각각의 출력 파일로 리다이렉션되는 디렉터리(기본값 C:\k)
위에 언급된 스크립트가 적합하지 않은 경우, 다음 예제를 사용하여 nssm.exe를 수동으로 구성할 수 있다.
# flanneld.exe 등록
nssm install flanneld C:\flannel\flanneld.exe
nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface=<ManagementIP> --ip-masq=1 --kube-subnet-mgr=1
nssm set flanneld AppEnvironmentExtra NODE_NAME=<hostname>
nssm set flanneld AppDirectory C:\flannel
nssm start flanneld
# kubelet.exe 등록# Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다.
nssm install kubelet C:\k\kubelet.exe
nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
nssm set kubelet AppDirectory C:\k
nssm start kubelet
# kube-proxy.exe 등록 (l2bridge / host-gw)
nssm install kube-proxy C:\k\kube-proxy.exe
nssm set kube-proxy AppDirectory c:\k
nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=<hostname>--kubeconfig=c:\k\config --enable-dsr=false --log-dir=<log directory> --logtostderr=false
nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0
nssm set kube-proxy DependOnService kubelet
nssm start kube-proxy
# kube-proxy.exe 등록 (overlay / vxlan)
nssm install kube-proxy C:\k\kube-proxy.exe
nssm set kube-proxy AppDirectory c:\k
nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override=<hostname> --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip=<source-vip> --enable-dsr=false --log-dir=<log directory> --logtostderr=false
nssm set kube-proxy DependOnService kubelet
nssm start kube-proxy
초기 트러블슈팅을 위해 nssm.exe에서 다음 플래그를 사용하여 stdout 및 stderr을 출력 파일로 리다이렉션할 수 있다.
nssm set <Service Name> AppStdout C:\k\mysvc.log
nssm set <Service Name> AppStderr C:\k\mysvc.log
가상 머신을 사용하는 경우, 모든 VM 네트워크 어댑터에서 MAC 스푸핑이 활성화되어 있는지 확인한다.
내 윈도우 파드가 외부 리소스를 ping 할 수 없다.
윈도우 파드에는 현재 ICMP 프로토콜용으로 프로그래밍된 아웃바운드 규칙이 없다. 그러나 TCP/UDP는 지원된다. 클러스터 외부 리소스에 대한 연결을 시연하려는 경우, ping <IP>를 해당 curl <IP>명령으로 대체한다.
여전히 문제가 발생하는 경우, cni.conf의 네트워크 구성에 특별히 추가 확인이 필요하다. 언제든지 이 정적 파일을 편집할 수 있다. 구성 업데이트는 새로 생성된 모든 쿠버네티스 리소스에 적용된다.
쿠버네티스 네트워킹 요구 사항 중 하나(쿠버네티스 모델)는 클러스터 통신이 내부적으로 NAT 없이 발생하는 것이다. 이 요구 사항을 준수하기 위해 아웃바운드 NAT가 발생하지 않도록 하는 모든 통신에 대한 ExceptionList가 있다. 그러나 이것은 쿼리하려는 외부 IP를 ExceptionList에서 제외해야 함도 의미한다. 그래야만 윈도우 파드에서 발생하는 트래픽이 제대로 SNAT 되어 외부에서 응답을 받는다. 이와 관련하여 cni.conf의 ExceptionList는 다음과 같아야 한다.
이것은 플란넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 다시 시작하거나 쿠버네티스 마스터의 /run/flannel/subnet.env에서 윈도우 워커 노드의 C:\run\flannel\subnet.env로 파일을 수동으로 복사할 수 있고, FLANNEL_SUBNET 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 10.244.4.1/24가 필요한 경우이다.
이는 윈도우에서 현재 네트워킹 스택의 알려진 제약 사항이다. 그러나 윈도우 파드는 서비스 IP에 접근할 수 있다.
kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없다.
윈도우 네트워킹 스택에는 쿠버네티스 네트워킹이 작동하기 위한 가상 어댑터가 필요하다. 다음 명령이 (어드민 셸에서) 결과를 반환하지 않으면, Kubelet이 작동하는데 필요한 필수 구성 요소인 가상 네트워크 생성이 실패한 것이다.
Get-HnsNetwork | ? Name -ieq"cbr0"Get-NetAdapter | ? Name -Like"vEthernet (Ethernet*"
호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 InterfaceName 파라미터를 수정하는 것이 좋다. 그렇지 않으면 start-kubelet.ps1 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다.
내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.
pause 이미지가 OS 버전과 호환되는지 확인한다. 지침에서는 OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 조정해야 한다. 이미지는 Microsoft의 도커 리포지터리를 참조한다. 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가 :latest로 태그될 것으로 예상한다.
kubectl port-forward가 "unable to do port forwarding: wincat not found"로 실패한다.
이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다.
자체 pause 인프라 컨테이너를 빌드하려면 wincat을 포함해야 한다.
쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 필요하다.
"pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. mcr.microsoft.com/oss/kubernetes/pause:1.4.1을 사용하여 접근할 수 있다. 자세한 내용은 DOCKERFILE을 참고한다.
추가 조사
이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 윈도우 컨테이너를 실행하는데 도움을 받을 수 있다.
버그처럼 보이는 부분이 있거나 기능 요청을 하고 싶다면, GitHub 이슈 트래킹 시스템을 활용한다. GitHub에서 이슈를 열고 SIG-Windows에 할당할 수 있다. 먼저 이전에 보고된 이슈 목록을 검색하고 이슈에 대한 경험을 언급하고 추가 로그를 첨부해야 한다. SIG-Windows 슬랙은 티켓을 만들기 전에 초기 지원 및 트러블슈팅 아이디어를 얻을 수 있는 좋은 방법이기도 하다.
참고: 포트 매핑도 지원하지만, 간략한 예시를 위해 컨테이너 포트 80을 직접 서비스로 노출한다.
모든 노드가 건강한지 확인한다.
kubectl get nodes
서비스를 배포하고 파드 갱신을 지켜보자.
kubectl apply -f win-webserver.yaml
kubectl get pods -o wide -w
이 서비스가 정확히 배포되면 모든 파드는 Ready로 표기된다. 지켜보기를 중단하려면, Ctrl+C 를 누르자.
이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
윈도우 노드에 파드당 두 컨테이너, docker ps를 사용한다.
리눅스 마스터에서 나열된 두 파드, kubectl get pods를 사용한다.
네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 curl을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
파드와 파드 간에 통신, docker exec 나 kubectl exec를 이용해 파드 간에 핑(ping)한다(윈도우 노드를 여럿가지고 있다면 호스트를 달리하며).
서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 curl을 가상 서비스 IP 주소(kubectl get services로 보여지는)로 실행한다.
서비스 검색(discovery), 쿠버네티스 기본 DNS 접미사와 서비스 이름으로 curl을 실행한다.
인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 curl을 실행한다.
아웃바운드 연결, kubectl exec를 이용해서 파드에서 외부 IP 주소로 curl을 실행한다.
참고: 윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다.
가시성
워크로드에서 로그 캡쳐하기
로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을 파악할 수 있도록 하며 문제 해결의 핵심 요소이다. 윈도우 컨테이너와 워크로드 내의 윈도우 컨테이너가 리눅스 컨테이너와는 다르게 동작하기 때문에, 사용자가 로그를 수집하는 데 어려움을 겪었기에 운영 가시성이 제한되었다. 예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나 애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다. Microsoft의 오픈 소스 도구인 LogMonitor는 윈도우 컨테이너 안에 구성된 로그 소스를 모니터링하는 권장하는 방법이다. LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고 kubectl logs <pod> 에 의한 사용을 위해 STDOUT으로 파이프한다.
LogMonitor Github 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고, LogMonitor에 필요한 입력 지점을 추가해서 로그를 STDOUT으로 푸시한다.
설정 가능한 컨테이너 username 사용하기
쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. 여기에서 이에 대해 추가적으로 배울 수 있다.
그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기
쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. 윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 여기에서 알아보자.
테인트(Taint)와 톨러레이션(Toleration)
오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와 노드 셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기
사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다. 오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다.
kubernetes.io/os = [windows|linux]
kubernetes.io/arch = [amd64|arm64|...]
파드 사양에 노드 셀렉터를 "kubernetes.io/os": windows와 같이 지정하지 않았다면, 그 파드는 리눅스나 윈도우, 아무 호스트에나 스케줄링될 수 있다. 윈도우 컨테이너는 윈도우에서만 운영될 수 있고 리눅스 컨테이너는 리눅스에서만 운영될 수 있기 때문에 이는 문제를 일으킬 수 있다. 가장 좋은 방법은 노드 셀렉터를 사용하는 것이다.
그러나 많은 경우 사용자는 이미 존재하는 대량의 리눅스 컨테이너용 디플로이먼트를 가지고 있을 뿐만 아니라, 헬름(Helm) 차트 커뮤니티 같은 상용 구성의 에코시스템이나, 오퍼레이터(Operator) 같은 프로그래밍 방식의 파드 생성 사례가 있음을 알고 있다. 이런 상황에서는 노드 셀렉터를 추가하는 구성 변경을 망설일 수 있다. 이에 대한 대안은 테인트를 사용하는 것이다. Kubelet은 등록하는 동안 테인트를 설정할 수 있기 때문에, 윈도우에서만 운영할 때에 자동으로 테인트를 추가하기 쉽다.
예를 들면, --register-with-taints='os=windows:NoSchedule'
모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). 윈도우 파드가 윈도우 노드에 스케줄링되려면, 윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
클러스터는 컨트롤 플레인에서 관리하는
쿠버네티스 에이전트를 실행하는 노드(물리
또는 가상 머신)의 집합이다.
쿠버네티스 v1.20는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는,
쿠버네티스는 다음 기준을 모두 만족하는 설정을 수용하도록 설계되었다.
노드 당 파드 100 개 이하
노드 5000개 이하
전체 파드 150000개 이하
전체 컨테이너 300000개 이하
노드를 추가하거나 제거하여 클러스터를 확장할 수 있다. 이를 수행하는 방법은
클러스터 배포 방법에 따라 다르다.
클라우드 프로바이더 리소스 쿼터
여러 노드를 가지는 클러스터를 만들 때, 클라우드 프로바이더 쿼터 이슈를 피하기 위해
고려할 점은 다음과 같다.
다음과 같은 클라우드 리소스에 대한 쿼터 증가를 요청한다.
컴퓨터 인스턴스
CPU
스토리지 볼륨
사용 중인 IP 주소
패킷 필터링 규칙 세트
로드밸런서 개수
로그 스트림
일부 클라우드 프로바이더는 새로운 인스턴스 생성 속도에 상한이 있어, 클러스터 확장 작업 간 새로운 노드를 일괄적으로 배치하고, 배치 간에 일시 중지한다.
컨트롤 플레인 컴포넌트
대규모 클러스터의 경우, 충분한 컴퓨트 및 기타 리소스가 있는 컨트롤 플레인이
필요하다.
일반적으로 장애 영역 당 하나 또는 두 개의 컨트롤 플레인 인스턴스를
실행하고, 해당 인스턴스를 수직으로(vertically) 먼저 확장한 다음 (수직) 규모로 하락하는
지점에 도달한 후 수평으로(horizontally) 확장한다.
내결함성을 제공하려면 장애 영역 당 하나 이상의 인스턴스를 실행해야 한다. 쿠버네티스
노드는 동일한 장애 영역에 있는 컨트롤 플레인 엔드포인트로 트래픽을
자동으로 조정하지 않는다. 그러나, 클라우드 프로바이더는 이를 수행하기 위한 자체 메커니즘을 가지고 있을 수 있다.
예를 들어, 관리형 로드 밸런서를 사용하여 장애 영역 A 의
kubelet 및 파드에서 시작되는 트래픽을 전송하도록 로드 밸런서를 구성하고, 해당 트래픽을
A 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일 컨트롤 플레인 호스트 또는
엔드포인트 장애 영역 A 이 오프라인이 되면, 영역 A 의 노드에 대한
모든 컨트롤 플레인 트래픽이 이제 영역간에 전송되고 있음을 의미한다. 각 영역에서 여러 컨트롤 플레인 호스트를
실행하면 가용성이 낮아진다.
etcd 저장소
큰 클러스터의 성능 향상을 위해, 사용자는 이벤트 오브젝트를 각각의
전용 etcd 인스턴스에 저장한다.
클러스터 생성시의 부가 스트립트이다.
클러스터 생성 시에 (사용자 도구를 사용하여) 다음을 수행할 수 있다.
애드온의 기본 제한은 일반적으로 중소형 쿠버네티스 클러스터에서
각 애드온을 실행한 경험에서 수집된 데이터를 기반으로 한다. 대규모 클러스터에서
실행할 때, 애드온은 종종 기본 제한보다 많은 리소스를 소비한다.
이러한 값을 조정하지 않고 대규모 클러스터를 배포하면, 애드온이
메모리 제한에 계속 도달하기 때문에 지속적으로 종료될 수 있다.
또는, 애드온이 실행될 수 있지만 CPU 시간 슬라이스 제한으로 인해
성능이 저하된다.
클러스터 애드온 리소스 문제가 발생하지 않도록, 노드가 많은 클러스터를
만들 때, 다음 사항을 고려한다.
일부 애드온은 수직으로 확장된다. 클러스터 또는 전체 장애 영역을
제공하는 애드온 레플리카가 하나 있다. 이러한 애드온의 경우, 클러스터를 확장할 때
요청과 제한을 늘린다.
많은 애드온은 수평으로 확장된다. 더 많은 파드를 실행하여 용량을 추가하지만,
매우 큰 클러스터에서는 CPU 또는 메모리 제한을 약간 높여야 할 수도 있다.
VerticalPodAutoscaler는 recommender 모드에서 실행되어 요청 및 제한에 대한
제안 수치를 제공할 수 있다.
일부 애드온은 데몬셋(DaemonSet)에 의해 제어되는 노드 당 하나의 복사본으로 실행된다(예: 노드 수준 로그 수집기). 수평
확장 애드온의 경우와 유사하게, CPU 또는 메모리 제한을 약간 높여야
할 수도 있다.
다음 내용
VerticalPodAutoscaler 는 리소스 요청 및 파드 제한을 관리하는 데 도움이 되도록
클러스터에 배포할 수 있는 사용자 정의 리소스이다.
클러스터에 중요한 애드온을 포함하여 클러스터 컴포넌트를 확장하는 방법에 대한
자세한 내용은 Vertical Pod Autoscaler를
방문하여 배워본다.
클러스터 오토스케일러는
여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는
노드 수를 실행할 수 있도록 도와준다.
2.4.2 - 여러 영역에서 실행
이 페이지에서는 여러 영역에서 쿠버네티스를 실행하는 방법을 설명한다.
배경
쿠버네티스는 단일 쿠버네티스 클러스터가 여러 장애 영역에서
실행될 수 있도록 설계되었다. 일반적으로 이러한 영역은 지역(region) 이라는
논리적 그룹 내에 적합하다. 주요 클라우드 제공자는 지역을 일관된 기능 집합을
제공하는 장애 영역 집합(가용성 영역 이라고도 함)으로
정의한다. 지역 내에서 각 영역은 동일한 API 및
서비스를 제공한다.
일반적인 클라우드 아키텍처는 한 영역의 장애가 다른 영역의 서비스도
손상시킬 가능성을 최소화하는 것을 목표로 한다.
컨트롤 플레인 동작
모든 컨트롤 플레인 컴포넌트는
컴포넌트별로 복제되는 교환 가능한 리소스 풀로 실행을
지원한다.
클러스터 컨트롤 플레인을 배포할 때, 여러 장애 영역에
컨트롤 플레인 컴포넌트의 복제본을 배치한다. 가용성이
중요한 문제인 경우, 3개 이상의 장애 영역을 선택하고
각 개별 컨트롤 플레인 컴포넌트(API 서버, 스케줄러, etcd,
클러스터 컨트롤러 관리자)를 3개 이상의 장애 영역에 복제한다.
클라우드 컨트롤러 관리자를 실행 중인 경우 선택한
모든 장애 영역에 걸쳐 이를 복제해야 한다.
참고: 쿠버네티스는 API 서버 엔드포인트에 대한 교차 영역 복원성을 제공하지
않는다. DNS 라운드-로빈, SRV 레코드 또는 상태 확인 기능이 있는
써드파티 로드 밸런싱 솔루션을 포함하여 다양한 기술을 사용하여
클러스터 API 서버의 가용성을 향상시킬 수 있다.
노드가 시작되면, 각 노드의 kubelet이 쿠버네티스 API에서
특정 kubelet을 나타내는 노드 오브젝트에
레이블을 자동으로 추가한다.
이러한 레이블에는
영역 정보가 포함될 수 있다.
클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
파드 토폴로지 분배 제약 조건과
함께 노드 레이블을 사용하여
파드가 장애 도메인(지역, 영역, 특정 노드) 간 클러스터에
분산되는 방식을 제어할 수 있다.
이러한 힌트를 통해
스케줄러는
더 나은 예상 가용성을 위해 파드를 배치할 수 있으므로, 상관 관계가 있는
오류가 전체 워크로드에 영향을 미칠 위험을 줄일 수 있다.
예를 들어, 가능할 때마다 스테이트풀셋의
3개 복제본이 모두 서로 다른 영역에서 실행되도록 제약 조건을
설정할 수 있다. 각 워크로드에 사용 중인
가용 영역을 명시적으로 정의하지 않고 이를 선언적으로
정의할 수 있다.
여러 영역에 노드 분배
쿠버네티스의 코어는 사용자를 위해 노드를 생성하지 않는다. 사용자가 직접 수행하거나,
클러스터 API와 같은 도구를 사용하여
사용자 대신 노드를 관리해야 한다.
클러스터 API와 같은 도구를 사용하면 여러 장애 도메인에서
클러스터의 워커 노드로 실행할 머신 집합과 전체 영역 서비스 중단 시
클러스터를 자동으로 복구하는 규칙을 정의할 수 있다.
파드에 대한 수동 영역 할당
생성한 파드와 디플로이먼트, 스테이트풀셋, 잡(Job)과
같은 워크로드 리소스의 파드 템플릿에 노드 셀렉터 제약 조건을
적용할 수 있다.
영역에 대한 스토리지 접근
퍼시스턴트 볼륨이 생성되면, PersistentVolumeLabel어드미션 컨트롤러는
특정 영역에 연결된 모든 퍼시스턴트볼륨(PersistentVolume)에 영역 레이블을 자동으로
추가한다. 그런 다음 스케줄러는
NoVolumeZoneConflict 프레디케이트(predicate)를 통해 주어진 퍼시스턴트볼륨을 요구하는 파드가
해당 볼륨과 동일한 영역에만 배치되도록 한다.
해당 클래스의 스토리지가 사용할 수 있는 장애 도메인(영역)을 지정하는
퍼시스턴트볼륨클레임(PersistentVolumeClaims)에 대한
스토리지클래스(StorageClass)를 지정할 수 있다.
장애 도메인 또는 영역을 인식하는 스토리지클래스 구성에 대한 자세한 내용은
허용된 토폴로지를 참고한다.
네트워킹
쿠버네티스가 스스로 영역-인지(zone-aware) 네트워킹을 포함하지는 않는다.
네트워크 플러그인을
사용하여 클러스터 네트워킹을 구성할 수 있으며, 해당 네트워크 솔루션에는 영역별 요소가
있을 수 있다. 예를 들어, 클라우드 제공자가
type=LoadBalancer 를 사용하여 서비스를 지원하는 경우, 로드 밸런서는 지정된 연결을 처리하는
로드 밸런서 요소와 동일한 영역에서 실행 중인 파드로만 트래픽을 보낼 수 있다.
자세한 내용은 클라우드 제공자의 문서를 확인한다.
사용자 정의 또는 온-프레미스 배포의 경우, 비슷한 고려 사항이 적용된다.
다른 장애 영역 처리를 포함한 서비스와
인그레스(Ingress) 동작은
클러스터가 설정된 방식에 명확히 의존한다.
장애 복구
클러스터를 설정할 때, 한 지역의 모든 장애 영역이 동시에
오프라인 상태가 되는 경우 설정에서 서비스를 복원할 수 있는지
여부와 방법을 고려해야 할 수도 있다. 예를 들어, 영역에서 파드를 실행할 수 있는
노드가 적어도 하나 이상 있어야 하는가?
클러스터에 중요한 복구 작업이 클러스터에
적어도 하나 이상의 정상 노드에 의존하지 않는지 확인한다. 예를 들어, 모든 노드가
비정상인 경우, 하나 이상의 노드를 서비스할 수 있을 만큼 복구를 완료할 수 있도록 특별한
톨러레이션(toleration)으로
복구 작업을 실행해야 할 수 있다.
쿠버네티스는 이 문제에 대한 답을 제공하지 않는다. 그러나,
고려해야 할 사항이다.
다음 내용
스케줄러가 구성된 제약 조건을 준수하면서, 클러스터에 파드를 배치하는 방법을 알아보려면,
스케줄링과 축출(eviction)을 참고한다.
2.4.3 - 노드 구성 검증하기
노드 적합성 테스트
노드 적합성 테스트 는 노드의 시스템 검증과 기능 테스트를 제공하기 위해 컨테이너화된 테스트 프레임워크이다.
테스트는 노드가 쿠버네티스를 위한 최소 요구조건을 만족하는지를 검증한다. 그리고 테스트를 통과한 노드는 쿠버네티스 클러스터에 참
여할 자격이 주어진다.
노드 필수 구성 요소
노드 적합성 테스트를 실행하기 위해서는, 해당 노드는 표준 쿠버네티스 노드로서 동일한 전제조건을 만족해야 한다.
노드는 최소한 아래 데몬들이 설치되어 있어야 한다.
컨테이너 런타임 (Docker)
Kubelet
노드 적합성 테스트 실행
노드 적합성 테스트는 다음 순서로 진행된다.
kubelet에 대한 --kubeconfig 옵션의 값을 계산한다. 예를 들면, 다음과 같다.
--kubeconfig = / var / lib / kubelet / config.yaml.
테스트 프레임워크는 kubelet을 테스트하기 위해 로컬 컨트롤 플레인을 시작하기 때문에,
http://localhost:8080 을 API 서버의 URL로 사용한다.
사용할 수 있는 kubelet 커맨드 라인 파라미터가 몇 개 있다.
--pod-cidr: kubenet을 사용 중이라면, 임의의 CIDR을 Kubelet에 지정해주어야 한다. 예) --pod-cidr=10.180.0.0/24.
--cloud-provider: --cloud-provider=gce를 사용 중이라면, 테스트 실행 시에는 제거해야 한다.
다음 커맨드로 노드 적합성 테스트를 실행한다.
# $CONFIG_DIR는 Kublet의 파드 매니페스트 경로이다.# $LOG_DIR는 테스트 출력 경로이다.
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
k8s.gcr.io/node-test:0.2
다른 아키텍처에서 노드 적합성 테스트 실행
쿠버네티스는 다른 아키텍쳐용 노드 적합성 테스트 Docker 이미지도 제공한다.
Arch
Image
amd64
node-test-amd64
arm
node-test-arm
arm64
node-test-arm64
선택된 테스트 실행
특정 테스트만 실행하기 위해서는 환경 변수 FOCUS에 테스트하고자 하는 테스트를 정규식으로 지정한다.
특정 테스트를 건너뛰기 위해서는, 환경 변수 SKIP에 건너뛰고자 하는 테스트를 정규식으로 지정한다.
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e SKIP=MirrorPod \ # MirrorPod 테스트만 건너뛰고 모든 적합성 테스트를 실행한다
k8s.gcr.io/node-test:0.2
노드 적합성 테스트는 노드 e2e 테스트를 컨테이너화한 버전이다.
기본적으로, 모든 적합성 테스트를 실행한다.
이론적으로, 컨테이너와 필요한 볼륨을 적절히 설정했다면 어떤 노드 e2e 테스트도 수행할 수 있다.
하지만, 적합성 테스트가 아닌 테스트들은 훨씬 복잡한 설정이 필요하기 때문에 적합성 테스트만 실행하기를 강하게 추천한다.
주의 사항
테스트 후, 노드 적합성 테스트 이미지 및 기능 테스트에 사용된 이미지들을 포함하여 몇 개의 Docker 이미지들이 노드에 남는다.
테스트 후, 노드에 죽은 컨테이너가 남는다. 기능 테스트 도중에 생성된 컨테이너들이다.
2.4.4 - PKI 인증서 및 요구 조건
쿠버네티스는 TLS 위에 인증을 위해 PKI 인증서가 필요하다.
만약 kubeadm으로 쿠버네티스를 설치했다면, 클러스터에 필요한 인증서는 자동으로 생성된다.
또한 더 안전하게 자신이 소유한 인증서를 생성할 수 있다. 이를 테면, 개인키를 API 서버에 저장하지 않으므로 더 안전하게 보관할 수 있다.
이 페이지는 클러스터에 필요한 인증서를 설명한다.
위의 CA외에도, 서비스 계정 관리를 위한 공개/개인 키 쌍인 sa.key 와 sa.pub 을 얻는 것이 필요하다.
모든 인증서
이런 개인키를 API 서버에 복사하기 원치 않는다면, 모든 인증서를 스스로 생성할 수 있다.
필요한 인증서:
기본 CN
부모 CA
O (주체에서)
종류
호스트 (SAN)
kube-etcd
etcd-ca
server, client
localhost, 127.0.0.1
kube-etcd-peer
etcd-ca
server, client
<hostname>, <Host_IP>, localhost, 127.0.0.1
kube-etcd-healthcheck-client
etcd-ca
client
kube-apiserver-etcd-client
etcd-ca
system:masters
client
kube-apiserver
kubernetes-ca
server
<hostname>, <Host_IP>, <advertise_IP>, [1]
kube-apiserver-kubelet-client
kubernetes-ca
system:masters
client
front-proxy-client
kubernetes-front-proxy-ca
client
[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름(kubeadm 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, kubernetes, kubernetes.default, kubernetes.default.svc,
kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local)
반드시 매니페스트를 manifests/kube-controller-manager.yaml에 추가해야 한다.
scheduler.conf
kube-scheduler
반드시 매니페스트를 manifests/kube-scheduler.yaml에 추가해야 한다.
3 - 개념
개념 섹션을 통해 쿠버네티스 시스템을 구성하는 요소와 클러스터를 표현하는데 사용되는 추상 개념에 대해 배우고 쿠버네티스가 작동하는 방식에 대해 보다 깊이 이해할 수 있다.
3.1 - 개요
쿠버네티스와 그 컴포넌트에 대한 하이-레벨(high-level) 개요를 제공한다.
3.1.1 - 쿠버네티스란 무엇인가?
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다.
이 페이지에서는 쿠버네티스 개요를 설명한다.
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.
쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.
여정 돌아보기
시간이 지나면서 쿠버네티스가 왜 유용하게 되었는지 살펴보자.
전통적인 배포 시대:
초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 조직에게 많은 비용이 들었다.
가상화된 배포 시대: 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.
각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.
컨테이너 개발 시대: 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.
기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
리소스 격리: 애플리케이션 성능을 예측할 수 있다.
자원 사용량: 리소스 사용량: 고효율 고집적.
쿠버네티스가 왜 필요하고 무엇을 할 수 있나
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.
쿠버네티스는 다음을 제공한다.
서비스 디스커버리와 로드 밸런싱
쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
스토리지 오케스트레이션
쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
자동화된 롤아웃과 롤백
쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
자동화된 빈 패킹(bin packing)
컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
자동화된 복구(self-healing)
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
시크릿과 구성 관리
쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
쿠버네티스가 아닌 것
쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
쿠버네티스는:
지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
쿠버네티스 클러스터는 컨테이너화된 애플리케이션을 실행하는 노드라고
하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.
워커 노드는 애플리케이션의 구성요소인
파드를 호스트한다.
컨트롤 플레인은 워커 노드와
클러스터 내 파드를 관리한다. 프로덕션 환경에서는 일반적으로 컨트롤 플레인이
여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를
실행하므로 내결함성과 고가용성이 제공된다.
이 문서는 완전히 작동하는 쿠버네티스 클러스터를 갖기 위해 필요한
다양한 컴포넌트들에 대해 요약하고 정리한다.
여기에 모든 컴포넌트가 함께 있는 쿠버네티스 클러스터 다이어그램이 있다.
컨트롤 플레인 컴포넌트
컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 파드를 구동시키는 것)를 감지하고 반응한다.
컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고,
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 VM에서
실행되는 컨트롤 플레인 설정의 예제를 보려면
kubeadm을 사용하여 고가용성 클러스터 만들기를 확인해본다.
kube-apiserver
API 서버는 쿠버네티스 API를
노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다.
API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.
쿠버네티스 API 서버의 주요 구현은 kube-apiserver 이다.
kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다.
여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.
etcd
모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.
쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면,
이 데이터를 백업하는 계획은
필수이다.
논리적으로, 각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.
이들 컨트롤러는 다음을 포함한다.
노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을
유지시켜 주는 책임을 가진다.
엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.
cloud-controller-manager
클라우드별 컨트롤 로직을 포함하는 쿠버네티스
컨트롤 플레인 컴포넌트이다.
클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고,
해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.
cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다.
자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우
클러스터에는 클라우드 컨트롤러 매니저가 없다.
kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로
독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다.
수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다.
다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다.
노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것
라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것
서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것
노드 컴포넌트
노드 컴포넌트는 동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다.
kubelet
클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.
Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.
kube-proxy
kube-proxy는 클러스터의 각
노드에서
실행되는 네트워크 프록시로, 쿠버네티스의
서비스 개념의 구현부이다.
kube-proxy는
노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크
세션이나 클러스터 바깥에서 파드로 네트워크 통신을
할 수 있도록 해준다.
kube-proxy는 운영 체제에 가용한 패킷
필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인
Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
자세한 내용은 쿠버네티스 Protobuf 직렬화 디자인 제안과
API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
IDL(인터페이스 정의 언어) 파일을 참고한다.
API 리소스는 API 그룹, 리소스 유형, 네임스페이스
(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 API 버전 간의
변환을 투명하게 처리한다. 서로 다른 모든 버전은 실제로
동일한 지속 데이터의 표현이다. API 서버는 여러 API 버전을 통해
동일한 기본 데이터를 제공할 수 있다.
예를 들어, 동일한 리소스에 대해 v1 과 v1beta1 이라는 두 가지 API 버전이
있다고 가정한다. 원래 API의 v1beta1 버전을 사용하여 오브젝트를
만든 경우, 나중에 v1beta1 또는 v1 API 버전을 사용하여 해당 오브젝트를
읽거나, 업데이트하거나, 삭제할 수 있다.
API 변경 사항
성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 설계했다.
쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 않고 다른 프로젝트가
적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
리소스 또는 필드를 제거하려면
API 지원 중단 정책을 따라야 한다.
쿠버네티스는 일반적으로 API 버전 v1 에서 안정 버전(GA)에 도달하면, 공식 쿠버네티스 API에
대한 호환성 유지를 강력하게 이행한다. 또한,
쿠버네티스는 가능한 경우 베타 API 버전에서도 호환성을 유지한다.
베타 API를 채택하면 기능이 안정된 후에도 해당 API를 사용하여 클러스터와
계속 상호 작용할 수 있다.
참고: 쿠버네티스는 또한 알파 API 버전에 대한 호환성을 유지하는 것을 목표로 하지만, 일부
상황에서는 호환성이 깨진다. 알파 API 버전을 사용하는 경우, API가 변경된 경우 클러스터를
업그레이드할 때 쿠버네티스에 대한 릴리스 정보를 확인한다.
API 변경 사항에서
호환 가능한 변경 사항을 구성하고, API를 변경하는 방법에 대해 알아본다.
3.1.4 - 쿠버네티스 오브젝트로 작업하기
쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다. 쿠버네티스 오브젝트 모델과 쿠버네티스 오브젝트를 사용하는 방법에 대해 학습한다.
3.1.4.1 - 쿠버네티스 오브젝트 이해하기
이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를 어떻게 .yaml 형식으로 표현할 수 있는지에 대해 설명한다.
쿠버네티스 오브젝트 이해하기
쿠버네티스 오브젝트 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.
어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
그 애플리케이션이 이용할 수 있는 리소스
그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 의도한 상태 가 된다.
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, 쿠버네티스 API를 이용해야 한다. 예를 들어, kubectl 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 클라이언트 라이브러리 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
오브젝트 명세(spec)와 상태(status)
거의 모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는
두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 spec 과 오브젝트 status 이다.
spec을 가진 오브젝트는 오브젝트를 생성할 때 리소스에
원하는 특징(의도한 상태)에 대한 설명을
제공해서 설정한다.
status 는 쿠버네티스 시스템과 컴포넌트에 의해 제공되고
업데이트된 오브젝트의 현재 상태 를 설명한다. 쿠버네티스
컨트롤 플레인은 모든 오브젝트의
실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 그리고
능동적으로 관리한다.
예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을
표현해줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트
spec에 3개의 애플리케이션 레플리카가 동작되도록
설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어
spec에 일치되도록 상태를 업데이트하여 3개의 의도한
애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가
어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이
경우에는 대체 인스턴스를 시작하여)을 통해
spec과 status간의 차이에 대응한다.
쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 kubectl을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. 대부분의 경우 정보를 .yaml 파일로 kubectl에 제공한다.kubectl은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다.
여기 쿠버네티스 디플로이먼트를 위한 필수 필드와 오브젝트 spec을 보여주는 .yaml 파일 예시가 있다.
apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:app:nginxreplicas:2# tells deployment to run 2 pods matching the templatetemplate:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.14.2ports:- containerPort:80
위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는
kubectl 커맨드-라인 인터페이스에 인자값으로 .yaml 파일을 건네
kubectl apply 커맨드를 이용하는 것이다. 다음 예시와 같다.
생성하고자 하는 쿠버네티스 오브젝트에 대한 .yaml 파일 내, 다음 필드를 위한 값들을 설정해 줘야한다.
apiVersion - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
kind - 어떤 종류의 오브젝트를 생성하고자 하는지
metadata - 이름 문자열, UID, 그리고 선택적인 네임스페이스를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
spec - 오브젝트에 대해 어떤 상태를 의도하는지
오브젝트 spec에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. Kubernetes API Reference 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
예를 들어, 파드에 대한 spec 포맷은
PodSpec v1 Core
에서 확인할 수 있고, 디플로이먼트에 대한 spec 포맷은
DeploymentSpec v1 apps에서 확인할 수 있다.
경고: 명령형 replace 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고
구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다.
이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는
사용하지 말아야한다.
예를 들어 LoadBalancer 유형의 서비스는 클러스터의 구성과 별도로
externalIPs 필드가 업데이트된다.
예시
구성 파일에 정의된 오브젝트를 생성한다.
kubectl create -f nginx.yaml
두 개의 구성 파일에 정의된 오브젝트를 삭제한다.
kubectl delete -f nginx.yaml -f redis.yaml
활성 동작하는 구성을 덮어씀으로써 구성 파일에 정의된 오브젝트를
업데이트한다.
kubectl replace -f nginx.yaml
트레이드 오프
명령형 커맨드에 비해 장점은 다음과 같다.
오브젝트 구성은 Git과 같은 소스 컨트롤 시스템에 보관할 수 있다.
오브젝트 구성은 푸시와 감사 추적 전에 변경사항을 검토하는 것과 같은 프로세스들과 통합할 수 있다.
오브젝트 구성은 새로운 오브젝트 생성을 위한 템플릿을 제공한다.
명령형 커맨드에 비해 단점은 다음과 같다.
오브젝트 구성은 오브젝트 스키마에 대한 기본적인 이해를 필요로 한다.
오브젝트 구성은 YAML 파일을 기록하는 추가적인 과정을 필요로 한다.
선언형 오브젝트 구성에 비해 장점은 다음과 같다.
명령형 오브젝트 구성의 동작은 보다 간결하고 이해하기 쉽다.
쿠버네티스 버전 1.5 부터는 더 성숙한 명령형 오브젝트 구성을 제공한다.
선언형 오브젝트 구성에 비해 단점은 다음과 같다.
명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 가장 적합하다.
활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.
선언형 오브젝트 구성
선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
kubectl에 의해 오브젝트마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해
다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.
참고: 선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에
다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다.
이것은 전체 오브젝트 구성 변경을 위한 replace API를
사용하는 대신, patch API를 사용하여 인지되는 차이만
작성하기 때문에 가능하다.
예시
configs 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 diff
하고 나서 적용할 수 있다.
참고: 쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, kube- 접두사로 네임스페이스를 생성하지 않는다.
네임스페이스 조회
사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다.
kubectl get namespace
NAME STATUS AGE
default Active 1d
kube-node-lease Active 1d
kube-public Active 1d
kube-system Active 1d
쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다.
default 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
kube-system 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
kube-public 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
kube-node-lease 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스
요청에 네임스페이스 설정하기
현재 요청에 대한 네임스페이스를 설정하기 위해서 --namespace 플래그를 사용한다.
예를 들면,
kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>
선호하는 네임스페이스 설정하기
이후 모든 kubectl 명령에서 사용하는 네임스페이스를 컨텍스트에
영구적으로 저장할 수 있다.
서비스를 생성하면 해당
DNS 엔트리가 생성된다.
이 엔트리는 <서비스-이름>.<네임스페이스-이름>.svc.cluster.local의 형식을 갖는데,
이는 컨테이너가 <서비스-이름>만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다.
네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 이름(FQDN)을 사용해야 한다.
모든 오브젝트가 네임스페이스에 속하지는 않음
대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
그리고 노드나
퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
네임스페이스에도 속하지 않는다.
다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다.
# 네임스페이스에 속하는 리소스
kubectl api-resources --namespaced=true# 네임스페이스에 속하지 않는 리소스
kubectl api-resources --namespaced=false
레이블 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다.
레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다.
레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 레이블은 오브젝트를 생성할 때에 붙이거나 생성 이후에 붙이거나 언제든지 수정이 가능하다.
오브젝트마다 키와 값으로 레이블을 정의할 수 있다. 오브젝트의 키는 고유한 값이어야 한다.
레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에
적합하다. 식별되지 않는 정보는
어노테이션으로 기록해야 한다.
사용 동기
레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.
서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리스 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.
이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
구문과 캐릭터 셋
레이블 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(/)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자([a-z0-9A-Z])이며, 대시(-), 밑줄(_), 점(.)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야 하며, 점(.)과 전체 253자 이하, 슬래시(/)로 구분되는 DNS 레이블이다.
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: kube-scheduler, kube-controller-manager, kube-apiserver, kubectl 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
kubernetes.io/와 k8s.io/ 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
유효한 레이블 값은 다음과 같다.
63 자 이하 여야 하고(공백이면 안 됨),
시작과 끝은 알파벳과 숫자([a-z0-9A-Z])이며,
알파벳과 숫자, 대시(-), 밑줄(_), 점(.)를 중간에 포함할 수 있다.
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자([a-z0-9A-Z])이며, 대시(-), 밑줄(_), 점(.)과 함께 사용할 수 있다.
다음의 예시는 파드에 environment: production 과 app: nginx 2개의 레이블이 있는 구성 파일이다.
이름과 UID와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.
레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다.
API는 현재 일치성 기준 과 집합성 기준 이라는 두 종류의 셀렉터를 지원한다.
레이블 셀렉터는 쉼표로 구분된 다양한 요구사항 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(&&) 연산자로 구분되는 역할을 하도록 해야 한다.
비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다.
셀렉터를 사용하는 API 유형은 유효성과 의미를
문서화해야 한다.
참고: 레플리카셋(ReplicaSet)과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
주의: 일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 OR (||) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다.
일치성 기준 요건
일치성 기준 또는 불일치 기준 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만, 레이블의 명시된 제약 조건을 모두 만족해야 한다.
=,==,!= 이 세 가지 연산자만 허용한다. 처음 두 개의 연산자의 일치성(그리고 동의어), 나머지는 불일치 를 의미한다. 예를 들면,
environment = production
tier != frontend
전자는 environment를 키로 가지는 것과 production을 값으로 가지는 모든 리소스를 선택한다.
후자는 tier를 키로 가지고, 값을 frontend를 가지는 리소스를 제외한 모든 리소스를 선택하고, tier를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다.
environment=production,tier!=frontend 처럼 쉼표를 통해 한 문장으로 frontend를 제외한 production을 필터링할 수 있다.
일치성 기준 레이블 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다.
예를 들어, 아래 샘플 파드는 "accelerator=nvidia-tesla-p100"
레이블을 가진 노드를 선택한다.
집합성 기준 레이블 요건에 따라 값 집합을 키로 필터링할 수 있다. in,notin과 exists(키 식별자만 해당)의 3개의 연산자를 지원한다. 예를 들면,
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
첫 번째 예시에서 키가 environment이고 값이 production 또는 qa인 모든 리소스를 선택한다.
두 번째 예시에서 키가 tier이고 값이 frontend와 backend를 가지는 리소스를 제외한 모든 리소스와 키로 tier를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
세 번째 예시에서 레이블의 값에 상관없이 키가 partition을 포함하는 모든 리소스를 선택한다.
네 번째 예시에서 레이블의 값에 상관없이 키가 partition을 포함하지 않는 모든 리소스를 선택한다.
마찬가지로 쉼표는 AND 연산자로 작동한다. 따라서 partition,environment notin (qa)와 같이 사용하면 값과 상관없이 키가 partition인 것과 키가 environment이고 값이 qa와 다른 리소스를 필터링할 수 있다.
집합성 기준 레이블 셀렉터는 일반적으로 environment=production과 environment in (production)을 같은 것으로 본다. 유사하게는 !=과 notin을 같은 것으로 본다.
집합성 기준 요건은 일치성 기준 요건과 조합해서 사용할 수 있다. 예를 들어 partition in (customerA, customerB),environment!=qa
API
LIST와 WATCH 필터링
LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 두 가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
일치성 기준 요건: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
집합성 기준 요건: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29
두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, kubectl로 apiserver를 대상으로 일치성 기준 으로 하는 셀렉터를 다음과 같이 이용할 수 있다.
kubectl get pods -l environment=production,tier=frontend
또는 집합성 기준 요건을 사용하면
kubectl get pods -l 'environment in (production),tier in (frontend)'
앞서 안내한 것처럼 집합성 기준 요건은 더 보여준다. 예시에서 다음과 같이 OR 연산자를 구현할 수 있다.
kubectl get pods -l 'environment in (production, qa)'
또는 exists 연산자에 불일치한 것으로 제한할 수 있다.
kubectl get pods -l 'environment,environment notin (frontend)'
matchLabels는 {key,value}의 쌍과 매칭된다. matchLabels에 매칭된 단일 {key,value}는 matchExpressions의 요소와 같으며 key 필드는 "key"로, operator는 "In" 그리고 values에는 "value"만 나열되어 있다. matchExpressions는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. matchLabels와 matchExpressions 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
노드 셋 선택
레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다.
자세한 내용은 노드 선택 문서를 참조한다.
3.1.4.6 - 어노테이션
쿠버네티스 어노테이션을 사용하여 임의의 비-식별 메타데이터를
오브젝트에 첨부할 수 있다. 도구 및 라이브러리와 같은 클라이언트는 이 메타데이터를 검색할 수 있다.
오브젝트에 메타데이터 첨부
레이블이나 어노테이션을 사용하여 쿠버네티스
오브젝트에 메타데이터를 첨부할 수 있다. 레이블을 사용하여 오브젝트를 선택하고, 특정 조건을 만족하는 오브젝트
컬렉션을 찾을 수 있다. 반면에, 어노테이션은
오브젝트를 식별하고 선택하는데 사용되지 않는다. 어노테이션의 메타데이터는
작거나 크고, 구조적이거나 구조적이지 않을 수 있으며, 레이블에서
허용되지 않는 문자를 포함할 수 있다.
필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은
클라이언트 또는 서버가 설정한 기본 값,
자동 생성된 필드, 그리고
오토사이징 또는 오토스케일링 시스템에 의해 설정된 필드와 구분된다.
빌드, 릴리스, 또는 타임 스탬프, 릴리스 ID, git 브랜치,
PR 번호, 이미지 해시 및 레지스트리 주소와 같은 이미지 정보.
로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터.
디버깅 목적으로 사용될 수 있는 클라이언트 라이브러리 또는 도구 정보:
예를 들면, 이름, 버전, 그리고 빌드 정보.
다른 생태계 구성 요소의 관련 오브젝트 URL과 같은
사용자 또는 도구/시스템 출처 정보.
경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은
해당 정보를 찾을 수 있는 디렉터리 진입점.
행동을 수정하거나 비표준 기능을 수행하기 위한
최종 사용자의 지시 사항.
어노테이션을 사용하는 대신, 이 유형의 정보를
외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
공유 클라이언트 라이브러리와 도구 생성을
훨씬 더 어렵게 만들 수 있다.
문법과 캐릭터 셋
어노테이션 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(/)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자([a-z0-9A-Z])로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(-), 밑줄(_), 점(.)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 서브도메인이어야 한다. 점(.)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(/)가 붙는다.
접두사가 생략되면, 어노테이션 키는 사용자에게 비공개로 간주된다. 최종 사용자 오브젝트에 어노테이션을 추가하는 자동화된 시스템 구성 요소(예 :kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, 또는 다른 써드파티 자동화)는 접두사를 지정해야 한다.
kubernetes.io/와 k8s.io/ 접두사는 쿠버네티스 핵심 구성 요소를 위해 예약되어 있다.
다음은 imageregistry: https://hub.docker.com/ 어노테이션이 있는 파드의 구성 파일 예시이다.
필드 셀렉터 는 한 개 이상의 리소스 필드 값에 따라 쿠버네티스 리소스를 선택하기 위해 사용된다. 필드 셀렉터 쿼리의 예시는 다음과 같다.
metadata.name=my-service
metadata.namespace!=default
status.phase=Pending
다음의 kubectl 커맨드는 status.phase 필드의 값이 Running 인 모든 파드를 선택한다.
kubectl get pods --field-selector status.phase=Running
참고: 필드 셀렉터는 본질적으로 리소스 필터 이다. 기본적으로 적용되는 셀렉터나 필드는 없으며, 이는 명시된 종류의 모든 리소스가 선택된다는 것을 의미한다. 여기에 따라오는 kubectl 쿼리인 kubectl get pods 와 kubectl get pods --field-selector "" 는 동일하다.
사용 가능한 필드
사용 가능한 필드는 쿠버네티스의 리소스 종류에 따라서 다르다. 모든 리소스 종류는 metadata.name 과 metadata.namespace 필드 셀렉터를 사용할 수 있다. 사용할 수 없는 필드 셀렉터를 사용하면 다음과 같이 에러를 출력한다.
kubectl get ingress --field-selector foo.bar=baz
Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"
사용 가능한 연산자
필드 셀렉터에서 =, ==, != 연산자를 사용할 수 있다 (=와 ==는 동일한 의미이다). 예를 들면, 다음의 kubectl 커맨드는 default 네임스페이스에 속해있지 않은 모든 쿠버네티스 서비스를 선택한다.
kubectl get services --all-namespaces --field-selector metadata.namespace!=default
연계되는 셀렉터
레이블을 비롯한 다른 셀렉터처럼, 쉼표로 구분되는 목록을 통해 필드 셀렉터를 연계해서 사용할 수 있다. 다음의 kubectl 커맨드는 status.phase 필드가 Running 이 아니고, spec.restartPolicy 필드가 Always 인 모든 파드를 선택한다.
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
여러 개의 리소스 종류
필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 kubectl 커맨드는 default 네임스페이스에 속해있지 않은 모든 스테이트풀셋(StatefulSet)과 서비스를 선택한다.
kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
3.1.4.8 - 권장 레이블
kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝트를 시각화 하고 관리할 수 있다.
공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고
도구들이 상호 운용적으로 작동할 수 있도록 한다.
권장 레이블은 지원 도구 외에도 쿼리하는 방식으로
애플리케이션을 식별하게 한다.
메타데이터는 애플리케이션 의 개념을 중심으로 정리된다.
쿠버네티스는 플랫폼 서비스(PaaS)가 아니며 애플리케이션에 대해 공식적인 개념이 없거나 강요하지 않는다.
대신 애플리케이션은 비공식적이며 메타데이터로 설명된다.
애플리케이션에 포함된 정의는 유연하다.
참고: 메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만
코어 도구에는 필요하지 않다.
공유 레이블과 주석에는 공통 접두사인 app.kubernetes.io 가 있다.
접두사가 없는 레이블은 사용자가 개인적으로 사용할 수 있다.
공유 접두사는 공유 레이블이 사용자 정의 레이블을 방해하지 않도록 한다.
레이블
레이블을 최대한 활용하려면 모든 리소스 오브젝트에
적용해야 한다.
Key
Description
Example
Type
app.kubernetes.io/name
애플리케이션 이름
mysql
문자열
app.kubernetes.io/instance
애플리케이션의 인스턴스를 식별하는 고유한 이름
mysql-abcxzy
문자열
app.kubernetes.io/version
애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.)
애플리케이션은 동일한 쿠버네티스 클러스터에,
심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에
WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다.
예를 들어 WordPress는 애플리케이션 이름으로 app.kubernetes.io/name 이라는 레이블에 wordpress 라는 값을 가지며,
애플리케이션 인스턴스 이름으로는 app.kubernetes.io/instance 라는 레이블에
wordpress-abcxzy 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를
식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
예시
위 레이블을 사용하는 다른 방식에 대한 예시는 다양한 복잡성이 있다.
단순한 스테이트리스 서비스
Deployment 와 Service 오브젝트를 통해 배포된 단순한 스테이트리스 서비스의 경우를 보자. 다음 두 식별자는 레이블을 가장 간단한 형태로 사용하는 방법을 나타낸다.
쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는
kubelet이 노드의 metadata.name 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다.
노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에
대해 무시된다.
참고:
쿠버네티스는 유효하지 않은 노드 오브젝트를 유지하고, 노드가
정상적인지 확인한다.
상태 확인을 중지하려면 사용자 또는 컨트롤러에서
노드 오브젝트를 명시적으로 삭제해야 한다.
이름은 노드를 식별한다. 두 노드는
동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가
동일한 오브젝트라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한
상태(예: 네트워크 설정, 루트 디스크 내용)를 갖는다고 암시적으로 가정한다. 인스턴스가
이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나
업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고
업데이트 후 다시 추가해야 한다.
노드에 대한 자체-등록
kubelet 플래그 --register-node는 참(기본값)일 경우, kubelet 은 API 서버에
스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다.
자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.
--kubeconfig - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.
--cloud-provider - 자신에 대한 메터데이터를 읽기 위해 어떻게 클라우드 제공자와 소통할지에 대한 방법.
--register-node - 자동으로 API 서버에 등록.
--register-with-taints - 주어진 테인트(taint) 리스트(콤마로 분리된 <key>=<value>:<effect>)를 가진 노드 등록.
HostName: 노드의 커널에 의해 알려진 호스트명이다. --hostname-override 파라미터를 통해 치환될 수 있다.
ExternalIP: 일반적으로 노드의 IP 주소는 외부로 라우트 가능 (클러스터 외부에서 이용 가능) 하다 .
InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다.
컨디션
conditions 필드는 모든 Running 노드의 상태를 기술한다. 컨디션의 예로 다음을 포함한다.
노드 컨디션과 각 컨디션이 적용되는 시기에 대한 설명들이다.
노드 컨디션
설명
Ready
노드가 상태 양호하며 파드를 수용할 준비가 되어 있는 경우 True, 노드의 상태가 불량하여 파드를 수용하지 못할 경우 False, 그리고 노드 컨트롤러가 마지막 node-monitor-grace-period (기본값 40 기간 동안 노드로부터 응답을 받지 못한 경우) Unknown
DiskPressure
디스크 사이즈 상에 압박이 있는 경우, 즉 디스크 용량이 넉넉치 않은 경우 True, 반대의 경우 False
MemoryPressure
노드 메모리 상에 압박이 있는 경우, 즉 노드 메모리가 넉넉치 않은 경우 True, 반대의 경우 False
PIDPressure
프로세스 상에 압박이 있는 경우, 즉 노드 상에 많은 프로세스들이 존재하는 경우 True, 반대의 경우 False
NetworkUnavailable
노드에 대해 네트워크가 올바르게 구성되지 않은 경우 True, 반대의 경우 False
참고: 커맨드 라인 도구를 사용해서 코드화된 노드의 세부 정보를 출력하는 경우 조건에는
SchedulingDisabled 이 포함된다. SchedulingDisabled 은 쿠버네티스 API의 조건이 아니며,
대신 코드화된 노드는 사양에 스케줄 불가로 표시된다.
노드 컨디션은 JSON 오브젝트로 표현된다. 예를 들어, 다음 응답은 상태 양호한 노드를 나타낸다.
ready 컨디션의 상태가 pod-eviction-timeout (kube-controller-manager에 전달된 인수) 보다 더 길게 Unknown 또는 False로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 5분 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를
강제로 삭제하지 않는다. 파드가 Terminating 또는 Unknown 상태로 있을 때 접근 불가한 노드 상에서
동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에
대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로
탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다.
쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가
apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
테인트(taints)를 생성한다.
스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다.
또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다.
노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에
(CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다.
두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의
사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서
동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는
해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우,
노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
다음을 담당한다.
노드 다운과 같은 어떤 이유로 노드 컨트롤러가
하트비트 수신이 중단되는 경우 NodeStatus의 NodeReady
컨디션을 ConditionUnknown으로 업데이트 한다.
노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다.
ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
파드를 축출하기 시작하는 값은 5분이다.
노드 컨트롤러는 매 --node-monitor-period 초 마다 각 노드의 상태를 체크한다.
하트비트
쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다.
하트비트의 두 가지 형태는 NodeStatus 와
리스(Lease) 오브젝트이다.
각 노드에는 kube-node-lease 라는
네임스페이스 에 관련된 리스 오브젝트가 있다.
리스는 경량 리소스로, 클러스터가 확장될 때
노드의 하트비트 성능을 향상 시킨다.
kubelet은 NodeStatus 와 리스 오브젝트를 생성하고 업데이트 할
의무가 있다.
kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우,
NodeStatus 를 업데이트 한다. NodeStatus 의 기본 업데이트
주기는 5분으로, 연결할 수 없는 노드의 시간 제한인 40초
보다 훨씬 길다.
kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기).
리스 업데이트는 NodeStatus 업데이트와는
독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며
7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다.
안정성
대부분의 경우, 노드 컨트롤러는 초당 --node-eviction-rate(기본값 0.1)로
축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여
파드 축출을 하지 않는다는 의미가 된다.
노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
체크한다(NodeReady 컨디션은 ConditionUnknown 또는
ConditionFalse 다.).
상태가 불량한 노드의 일부가 최소 --unhealthy-zone-threshold
(기본값 0.55)가 되면 축출 비율은 감소한다.
클러스터가 작으면 (즉 --large-cluster-size-threshold
노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
--secondary-node-eviction-rate(기본값 0.01)로 감소된다.
이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다.
노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이
장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다.
그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는
--node-eviction-rate 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이
완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다.
이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이
복원될 때까지 모든 축출을 중지하는 것으로 여긴다.
또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 NoExecute 테인트 상태의
노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다.
추가로, 노드 컨틀로러는 연결할 수 없거나, 준비되지 않은 노드와 같은 노드 문제에 상응하는
테인트를 추가한다.
이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.
주의:kubectl cordon 은 노드를 'unschedulable'로 표기하는데, 이는
서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에
사실상 cordon 된 노드에서 들어오는 로드 밸런서 트래픽을 제거하는 부작용을 갖는다.
노드 용량
노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의
양과 CPU의 수를 추적한다.
노드의 자체 등록은 등록하는 중에 용량을 보고한다.
수동으로 노드를 추가하는 경우 추가할 때
노드의 용량 정보를 설정해야 한다.
쿠버네티스 스케줄러는
노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다. 스케줄러는 노드 상에
컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다.
요청의 합은 kubelet에서 관리하는 모든 컨테이너를 포함하지만, 컨테이너 런타임에
의해 직접적으로 시작된 컨 테이너는 제외되고 kubelet의 컨트롤 범위
밖에서 실행되는 모든 프로세스도 제외된다.
노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 중요 파드의 파드 종료에 필요한 총 유예 기간에 해당한다.
ShutdownGracePeriodCriticalPods:
노드 종료 중에 중요 파드를 종료하는 데 사용되는 기간을 지정한다. 이는 ShutdownGracePeriod보다 작아야 한다.
예를 들어 ShutdownGracePeriod=30s, ShutdownGracePeriodCriticalPods=10s 인 경우 kubelet은 노드 종료를 30 초까지 지연시킨다. 종료하는 동안 처음 20(30-10) 초는 일반 파드의 유예 종료에 할당되고, 마지막 10 초는 중요 파드의 종료에 할당된다.
이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
노드에서 컨트롤 플레인으로의 통신
쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다. API 서버는 하나 이상의 클라이언트 인증 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
특히 익명의 요청 또는 서비스 어카운트 토큰이 허용되는 경우, 하나 이상의 권한 부여 형식을 사용해야 한다.
노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 kubelet TLS 부트스트랩을 참고한다.
API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다.
kubernetes 서비스(default 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다.
결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다.
컨트롤 플레인에서 노드로의 통신
컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다.
API 서버에서 kubelet으로의 통신
API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
파드에 대한 로그를 가져온다.
실행 중인 파드에 (kubectl을 통해) 연결한다.
kubelet의 포트-포워딩 기능을 제공한다.
이 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 서빙(serving) 인증서를 확인하지 않으므로, 연결이 중간자(man-in-the-middle) 공격의 대상이 되며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 안전하지 않다 .
이 연결을 확인하려면, --kubelet-certificate-authority 플래그를 사용하여 API 서버에 kubelet의 서빙 인증서를 확인하는 데 사용할 루트 인증서 번들을 제공한다.
이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 SSH 터널링을
사용한다.
API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 https: 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않는다. 그래서 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 현재는 안전하지 않다 .
SSH 터널
쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
Konnectivity 서비스
FEATURE STATE:Kubernetes v1.18 [beta]
SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서
노드 집합의 kubelet이 작업을 수행하기에 적합한
수의 파드를 실행하게 한다.
잡 컨트롤러는 어떤 파드 또는 컨테이너를 스스로 실행하지 않는다.
대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록
지시한다.
컨트롤 플레인의
다른 컴포넌트는 신규 정보
(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여,
결국 해당 작업을 완료시킨다.
새 잡을 생성하고 나면, 의도한 상태는 해당 잡을 완료하는 것이 된다.
잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게
만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서
잡이 완료에 가까워 지도록 한다.
또한, 컨트롤러는 오브젝트의 설정을 업데이트 한다.
예시: 잡을 위한 작업이 종료된 경우, 잡 컨트롤러는
잡 오브젝트가 Finished 로 표시되도록 업데이트한다.
(이것은 지금 방 온도가 설정한 온도인 것을 표시하기
위해 실내 온도 조절기의 빛을 끄는 것과 약간 비슷하다).
직접 제어
잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을
변경해야 할 필요가 있다.
예를 들어, 만약 컨트롤 루프를 사용해서
클러스터에 충분한 노드들이
있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록
현재 클러스터 외부의 무언가를 필요로 한다.
외부 상태와 상호 작용하는 컨트롤러는 API 서버에서 의도한
상태를 찾은 다음, 외부 시스템과 직접 통신해서
현재 상태를 보다 가깝게 만든다.
여기서 중요한 점은 컨트롤러가 의도한 상태를 가져오기 위해 약간의 변화를 주고,
현재 상태를 클러스터의 API 서버에 다시 보고한다는 것이다.
다른 컨트롤 루프는 보고된 데이터를 관찰하고 자체 조치를 할 수 있다.
온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가
서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는
쿠버네티스 확장을 통해
IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API 및
기타 서비스 등과 간접적으로 연동하여 이를 구현한다.
의도한 상태와 현재 상태
쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인
변화에 대응할 수 있다.
작업이 발생함에 따라 어떤 시점에서든 클러스터가
변경 될 수 있으며 컨트롤 루프가 자동으로 실패를 바로잡는다. 이는 잠재적으로,
클러스터가 안정적인 상태에 도달하지 못하는 것을 의미한다.
클러스터의 컨트롤러가 실행 중이고 유용한 변경을 수행할 수 있는 한,
전체 상태가 안정적인지 아닌지는 중요하지 않다.
디자인
디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을
관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프
(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로
만들기 위해 다른 종류의 리소스를 관리한다. 예를 들어, 잡 컨트롤러는
잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를
확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면,
잡은 다른 컨트롤러가 생성한다.
컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다,
간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를
허용하도록 디자인되었다.
참고:
동일한 종류의 오브젝트를 만들거나 업데이트하는 여러 컨트롤러가 있을 수 있다.
이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에
연결된 리소스에만 주의를 기울인다.
예를 들어, 디플로이먼트와 잡을 가지고 있다. 이 두 가지 모두 파드를 생성한다.
잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다.
이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는
정보(레이블)가 있기 때문이다.
디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의
자체("내장" 컨트롤러)로 제공되는 컨트롤러 예시이다.
쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로,
어떤 내장 컨트롤러가 실패하더라도 다른 컨트롤 플레인의 일부가 작업을 이어서 수행한다.
컨트롤 플레인의 외부에서 실행하는 컨트롤러를 찾아서 쿠버네티스를 확장할 수 있다.
또는, 원하는 경우 새 컨트롤러를 직접 작성할 수 있다.
소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나,
또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에
따라 달라진다.
클라우드 인프라스트럭쳐 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다.
쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭쳐를
신뢰한다.
클라우드 컨트롤러 매니저는 클라우드별 컨트롤 로직을 포함하는 쿠버네티스
컨트롤 플레인 컴포넌트이다.
클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고,
해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.
쿠버네티스와 기본 클라우드 인프라스터럭처 간의 상호 운용성 로직을
분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 공급자가
주요 쿠버네티스 프로젝트와 다른 속도로 기능들을 릴리스할 수 있도록 한다.
클라우드 컨트롤러 매니저는 다양한 클라우드 공급자가 자신의
플랫폼에 쿠버네티스를 통합할 수 있도록 하는 플러그인 메커니즘을 사용해서 구성된다.
디자인
클라우드 컨트롤러 매니저는 컨트롤 플레인에서 복제된 프로세스의 집합으로 실행된다(일반적으로,
파드의 컨테이너). 각 클라우드 컨트롤러 매니저는 단일
프로세스에 여러 컨트롤러를
구현한다.
참고: 또한 사용자는 클라우드 컨트롤러 매니저를 컨트롤 플레인의 일부가 아닌 쿠버네티스
애드온으로
실행할 수도 있다.
클라우드 컨트롤러 매니저의 기능
클라우드 컨틀롤러 매니저의 내부 컨트롤러에는 다음 컨트롤러들이 포함된다.
노드 컨트롤러
노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 노드
오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자
테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다.
컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다.
클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를
사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다.
노드의 호스트 이름과 네트워크 주소를 가져온다.
노드의 상태를 확인한다. 노드가 응답하지 않는 경우, 이 컨트롤러는 사용자가
이용하는 클라우드 공급자의 API를 통해 서버가 비활성화됨 / 삭제됨 / 종료됨인지 확인한다.
노드가 클라우드에서 삭제된 경우, 컨트롤러는 사용자의 쿠버네티스 클러스터에서 노드
오브젝트를 삭제한다.
일부 클라우드 공급자의 구현에서는 이를 노드 컨트롤러와 별도의 노드
라이프사이클 컨트롤러로 분리한다.
라우트 컨트롤러
라우트 컨트롤러는 사용자의 쿠버네티스 클러스터의 다른 노드에
있는 각각의 컨테이너가 서로 통신할 수 있도록 클라우드에서
라우트를 적절히 구성해야 한다.
클라우드 공급자에 따라 라우트 컨트롤러는 파드 네트워크
IP 주소 블록을 할당할 수도 있다.
서비스 컨트롤러
서비스 는 관리형 로드 밸런서,
IP 주소, 네트워크 패킷 필터링 그리고 대상 상태 확인과 같은
클라우드 인프라스트럭처 컴포넌트와 통합된다. 서비스 컨트롤러는 사용자의 클라우드
공급자 API와 상호 작용해서 필요한 서비스 리소스를 선언할 때
로드 밸런서와 기타 인프라스트럭처 컴포넌트를 설정한다.
인가
이 섹션에서는 클라우드 컨트롤러 매니저가 작업을 수행하기 위해
다양한 API 오브젝트에 필요한 접근 권한을 세분화한다.
노드 컨트롤러
노드 컨트롤러는 노드 오브젝트에서만 작동한다. 노드 오브젝트를 읽고,
수정하려면 전체 접근 권한이 필요하다.
v1/Node:
Get
List
Create
Update
Patch
Watch
Delete
라우트 컨트롤러
라우트 컨트롤러가 노드 오브젝트의 생성을 수신하고 적절하게
라우트를 구성한다. 노드 오브젝트에 대한 접근 권한이 필요하다.
v1/Node:
Get
서비스 컨트롤러
서비스 컨트롤러는 서비스 오브젝트 생성, 업데이트 그리고 삭제 이벤트를 수신한 다음 해당 서비스에 대한 엔드포인트를 적절하게 구성한다.
서비스에 접근하려면, 목록과 감시 접근 권한이 필요하다. 서비스를 업데이트하려면, 패치와 업데이트 접근 권한이 필요하다.
서비스에 대한 엔드포인트 리소스를 설정하려면 생성, 목록, 가져오기, 감시 그리고 업데이트에 대한 접근 권한이 필요하다.
v1/Service:
List
Get
Watch
Patch
Update
그 외의 것들
클라우드 컨트롤러 매니저의 핵심 구현을 위해 이벤트 오브젝트를 생성하고, 안전한 작동을 보장하기 위해 서비스어카운트(ServiceAccounts)를 생성해야 한다.
이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 CloudProvider 인터페이스를 구현한다.
실행하는 각 컨테이너는 반복 가능하다. 의존성이 포함된 표준화는
어디에서 실행하던지 동일한 동작을 얻는다는 것을
의미한다.
컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다.
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다.
컨테이너 이미지
컨테이너 이미지는 애플리케이션을
실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어있는(ready-to-run) 소프트웨어 패키지이다.
여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리,
그리고 모든 필수 설정에 대한 기본값이 포함된다.
설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를
변경할 수 없다. 컨테이너화된 애플리케이션이 있고
변경하려는 경우, 변경 사항이 포함된 새 이미지를 빌드한
다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다.
컨테이너 이미지는 애플리케이션과 모든 소프트웨어 의존성을 캡슐화하는 바이너리 데이터를
나타낸다. 컨테이너 이미지는 독립적으로 실행할 수 있고 런타임 환경에 대해
잘 정의된 가정을 만드는 실행 가능한 소프트웨어 번들이다.
일반적으로 파드에서
참조하기 전에 애플리케이션의 컨테이너 이미지를
생성해서 레지스트리로 푸시한다.
이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.
이미지 이름
컨테이너 이미지는 일반적으로 pause, example/mycontainer 또는 kube-apiserver 와 같은 이름을 부여한다.
이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들면, fictional.registry.example/imagename
과 같다. 그리고 포트 번호도 포함할 수 있다. 예를 들면, fictional.registry.example:10443/imagename 과 같다.
이미지 이름 부분 다음에 tag 를 추가할 수 있다(docker 와 podman
등의 명령과 함께 사용).
태그를 사용하면 동일한 시리즈 이미지의 다른 버전을 식별할 수 있다.
이미지 태그는 소문자와 대문자, 숫자, 밑줄(_),
마침표(.) 및 대시(-)로 구성된다.
이미지 태그 안에서 구분 문자(_, - 그리고 .)를
배치할 수 있는 위치에 대한 추가 규칙이 있다.
태그를 지정하지 않으면, 쿠버네티스는 태그 latest 를 의미한다고 가정한다.
주의:
프로덕션에서 컨테이너를 배포할 때는 latest 태그를 사용하지 않아야 한다.
실행 중인 이미지 버전을 추적하기가 어렵고
이전에 잘 동작하던 버전으로 롤백하기가 더 어렵다.
대신, v1.42.0 과 같은 의미있는 태그를 지정한다.
이미지 업데이트
디플로이먼트,
스테이트풀셋, 파드 또는 파드
템플릿은 포함하는 다른 오브젝트를 처음 만들 때 특별히 명시하지 않은 경우
기본적으로 해당 파드에 있는 모든 컨테이너의 풀(pull)
정책은 IfNotPresent로 설정된다. 이 정책은
kubelet이 이미 존재하는
이미지에 대한 풀을 생략하게 한다.
만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다.
컨테이너의 imagePullPolicy를 Always로 설정.
imagePullPolicy를 생략하고 :latest를 사용할 이미지의 태그로 사용,
쿠버네티스는 정책을 Always로 설정한다.
컨테이너의 imagePullPolicy 값은 오브젝트가 처음 created 일 때 항상
설정되고 나중에 이미지 태그가 변경되더라도 업데이트되지 않는다.
예를 들어, 태그가 :latest가 아닌 이미지로 디플로이먼트를 생성하고,
나중에 해당 디플로이먼트의 이미지를 :latest 태그로 업데이트하면
imagePullPolicy 필드가 Always 로 변경되지 않는다. 오브젝트를
처음 생성 한 후 모든 오브젝트의 풀 정책을 수동으로 변경해야 한다.
imagePullPolicy 가 특정값 없이 정의되면, Always 로 설정된다.
이미지 인덱스가 있는 다중 아키텍처 이미지
바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 컨테이너 이미지 인덱스를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 이미지 매니페스트를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, pause, example/mycontainer, kube-apiserver)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다.
쿠버네티스 자체는 일반적으로 -$(ARCH) 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 pause 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 pause-amd64 라고 하는 이미지를 생성한다.
프라이빗 레지스트리 사용
프라이빗 레지스트리는 해당 레지스트리에서 이미지를 읽을 수 있는 키를 요구할 것이다.
자격 증명(credential)은 여러 가지 방법으로 제공될 수 있다.
프라이빗 레지스트리에 대한 인증을 위한 노드 구성
모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음
클러스터 관리자에 의한 노드 구성 필요
미리 내려받은(pre-pulled) 이미지
모든 파드는 노드에 캐시된 모든 이미지를 사용 가능
셋업을 위해서는 모든 노드에 대해서 root 접근이 필요
파드에 ImagePullSecrets을 명시
자신의 키를 제공하는 파드만 프라이빗 레지스트리에 접근 가능
공급 업체별 또는 로컬 확장
사용자 정의 노드 구성을 사용하는 경우, 사용자(또는 클라우드
제공자)가 컨테이너 레지스트리에 대한 노드 인증 메커니즘을
구현할 수 있다.
이들 옵션은 아래에서 더 자세히 설명한다.
프라이빗 레지스트리에 인증하도록 노드 구성
노드에서 도커를 실행하는 경우, 프라이빗 컨테이너 레지스트리를 인증하도록
도커 컨테이너 런타임을 구성할 수 있다.
이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다.
참고: 기본 쿠버네티스는 도커 구성에서 auths 와 HttpHeaders 섹션만 지원한다.
도커 자격 증명 도우미(credHelpers 또는 credsStore)는 지원되지 않는다.
도커는 프라이빗 레지스트리를 위한 키를 $HOME/.dockercfg 또는 $HOME/.docker/config.json 파일에 저장한다. 만약 동일한 파일을
아래의 검색 경로 리스트에 넣으면, kubelete은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다.
{--root-dir:-/var/lib/kubelet}/config.json
{cwd of kubelet}/config.json
${HOME}/.docker/config.json
/.docker/config.json
{--root-dir:-/var/lib/kubelet}/.dockercfg
{cwd of kubelet}/.dockercfg
${HOME}/.dockercfg
/.dockercfg
참고: kubelet 프로세스의 환경 변수에서 HOME=/root 를 명시적으로 설정해야 할 수 있다.
프라이빗 레지스트리를 사용도록 사용자의 노드를 구성하기 위해서 권장되는 단계는 다음과 같다. 이
예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다.
사용하고 싶은 각 자격 증명 세트에 대해서 docker login [서버]를 실행한다. 이것은 여러분 PC의 $HOME/.docker/config.json를 업데이트한다.
편집기로 $HOME/.docker/config.json를 열여서 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다.
노드의 리스트를 구한다. 예를 들면 다음과 같다.
이름을 원하는 경우: nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )
IP를 원하는 경우: nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )
로컬의 .docker/config.json를 위의 검색 경로 리스트 중 하나에 복사한다.
이를 테스트하기 위한 예: for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done
참고: 프로덕션 클러스터의 경우, 이 설정을 필요한 모든 노드에 적용할 수 있도록
구성 관리 도구를 사용한다.
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
클러스터의 모든 노드가 반드시 동일한 .docker/config.json를 가져야 한다. 그렇지 않으면, 파드가
일부 노드에서만 실행되고 다른 노드에서는 실패할 것이다. 예를 들어, 노드 오토스케일링을 사용한다면, 각 인스턴스
템플릿은 .docker/config.json을 포함하거나 그것을 포함한 드라이브를 마운트해야 한다.
프라이빗 레지스트리 키가 .docker/config.json에 추가되고 나면 모든 파드는
프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다.
미리 내려받은 이미지
참고: Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 .dockercfg가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
참고: 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은
클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로
작동하지 않을 것이다.
기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 한다.
그러나, 컨테이너의 imagePullPolicy 속성이 IfNotPresent 또는 Never으로 설정되어 있다면,
로컬 이미지가 사용된다(우선적으로 또는 배타적으로).
레지스트리 인증의 대안으로 미리 풀 된 이미지에 의존하고 싶다면,
클러스터의 모든 노드가 동일한 미리 내려받은 이미지를 가지고 있는지 확인해야 한다.
이것은 특정 이미지를 속도를 위해 미리 로드하거나 프라이빗 레지스트리에 대한 인증의 대안으로 사용될 수 있다.
모든 파드는 미리 내려받은 이미지에 대해 읽기 접근 권한을 가질 것이다.
파드에 ImagePullSecrets 명시
참고: 이 방법은 프라이빗 레지스트리의 이미지를 기반으로 컨테이너를 실행하는 데
권장된다.
런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
구성은 파드의 컨테이너를 실행하는데 사용된다.
동기
서로 다른 파드간에 런타임클래스를 설정하여
성능대 보안의 균형을 유지할 수 있다.
예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우,
하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다.
그러면 몇가지 추가적인 오버헤드는 있지만
대체 런타임을 추가 분리하는 유익이 있다.
또한 런타임클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른
여러 파드를 실행할 수 있다.
셋업
CRI 구현(implementation)을 노드에 설정(런타임에 따라서).
상응하는 런타임클래스 리소스 생성.
1. CRI 구현을 노드에 설정
런타임클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다.
사용자의 CRI 구현에 따른 설정 방법은
연관된 문서를 통해서 확인한다(아래).
참고: 런타임클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정
(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다.
이종의(heterogeneous) 노드 설정을 지원하기 위해서는, 아래 스케줄을 참고한다.
해당 설정은 상응하는 handler 이름을 가지며, 이는 런타임클래스에 의해서 참조된다.
런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + -와 .문자)을 가져야 한다.
2. 상응하는 런타임클래스 리소스 생성
1단계에서 셋업 한 설정은 연관된 handler 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다.
각 런타임 핸들러(그리고 선택적으로 비어있는 "" 핸들러)에 대해서, 상응하는 런타임클래스 오브젝트를 생성한다.
현재 런타임클래스 리소스는 런타임클래스 이름(metadata.name)과 런타임 핸들러
(handler)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
apiVersion:node.k8s.io/v1 # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음kind:RuntimeClassmetadata:name:myclass # 런타임클래스는 해당 이름을 통해서 참조됨# 런타임클래스는 네임스페이스가 없는 리소스임handler:myconfiguration # 상응하는 CRI 설정의 이름임
RuntimeClass에 scheduling 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가
이를 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다.
scheduling이 설정되지 않은 경우 이 RuntimeClass는 모든 노드에서 지원되는 것으로 간주된다.
파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
해당 노드들은 runtimeClass.scheduling.nodeSelector 필드에서 선택되는 공통 레이블을 가져야한다.
런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로
각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우,
파드는 거부된다.
지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면,
tolerations를 런타임클래스에 추가할 수 있다. nodeSelector를 사용하면, 어드미션 시
해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된
노드의 합집합을 취한다.
파드 실행과 연관되는 오버헤드 리소스를 지정할 수 있다. 오버헤드를 선언하면
클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리를 할 수 있다.
PodOverhead를 사용하려면, PodOverhead 기능 게이트
를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.)
파드 오버헤드는 런타임 클래스에서 overhead 필드를 통해 정의된다. 이 필드를 사용하면,
해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가
쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.
Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.
클러스터 정보
컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
있다.
이 목록은 새로운 컨테이너의 파드 및 쿠버네티스 컨트롤 플레인 서비스와 동일한 네임스페이스 내에 있는 서비스로 한정된다.
이러한 환경 변수는 Docker 링크 구문과 일치한다.
bar 라는 이름의 컨테이너에 매핑되는 foo 라는 이름의 서비스에 대해서는,
다음의 형태로 변수가 정의된다.
FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
서비스에 지정된 IP 주소가 있고 DNS 애드온이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서
컨테이너 라이프사이클 훅 프레임워크를 사용하는 방법에 대해서 설명한다.
개요
Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로그래밍 언어 프레임워크와 유사하게,
쿠버네티스도 컨테이너에 라이프사이클 훅을 제공한다.
훅은 컨테이너가 관리 라이프사이클의 이벤트를 인지하고 상응하는
라이프사이클 훅이 실행될 때 핸들러에 구현된 코드를 실행할 수 있게 한다.
컨테이너 훅
컨테이너에 노출되는 훅은 두 가지가 있다.
PostStart
이 훅은 컨테이너가 생성된 직후에 실행된다.
그러나, 훅이 컨테이너 엔트리포인트에 앞서서 실행된다는 보장은 없다.
파라미터는 핸들러에 전달되지 않는다.
PreStop
이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합
등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미
terminated 또는 completed 상태인 경우에는 PreStop 훅 요청이 실패하며,
훅은 컨테이너를 중지하기 위한 TERM 신호가 보내지기 이전에 완료되어야 한다. 파드의 그레이스 종료
기간(termination grace period)의 초읽기는 PreStop 훅이 실행되기 전에 시작되어,
핸들러의 결과에 상관없이 컨테이너가 파드의 그레이스 종료 기간 내에 결국 종료되도록 한다.
어떠한 파라미터도 핸들러에게 전달되지 않는다.
컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
구현될 수 있는 컨테이너의 훅 핸들러에는 세 가지 유형이 있다.
Exec - 컨테이너의 cgroups와 네임스페이스 안에서, pre-stop.sh와 같은, 특정 커맨드를 실행.
커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
TCP - 컨테이너의 특정 포트에 대한 TCP 연결을 연다.
HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.
훅 핸들러 실행
컨테이너 라이프사이클 관리 훅이 호출되면,
쿠버네티스 관리 시스템은 훅 동작에 따라 핸들러를 실행하고,
httpGet 와 tcpSocket 은 kubelet 프로세스에 의해 실행되고, exec 은 컨테이너에서 실행된다.
훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 컨텍스트와 동기적으로 동작한다.
이것은 PostStart 훅에 대해서,
훅이 컨테이너 엔트리포인트와는 비동기적으로 동작함을 의미한다.
그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면,
컨테이너는 running 상태에 이르지 못한다.
PreStop 훅은 컨테이너 중지 신호에서 비동기적으로 실행되지 않는다. 훅은
TERM 신호를 보내기 전에 실행을 완료해야 한다. 실행 중에 PreStop 훅이 중단되면,
파드의 단계는 Terminating 이며 terminationGracePeriodSeconds 가
만료된 후 파드가 종료될 때까지 남아 있다. 이 유예 기간은 PreStop 훅이
실행되고 컨테이너가 정상적으로 중지되는 데 걸리는 총 시간에 적용된다. 예를 들어,
terminationGracePeriodSeconds 가 60이고, 훅이 완료되는 데 55초가 걸리고,
컨테이너가 신호를 수신한 후 정상적으로 중지하는 데 10초가 걸리면, terminationGracePeriodSeconds 이후
컨테이너가 정상적으로 중지되기 전에 종료된다. 이 두 가지 일이 발생하는 데
걸리는 총 시간(55+10)보다 적다.
만약 PostStart 또는 PreStop 훅이 실패하면,
그것은 컨테이너를 종료시킨다.
사용자는 훅 핸들러를 가능한 한 가볍게 만들어야 한다.
그러나, 컨테이너가 멈추기 전 상태를 저장하는 것과 같이,
오래 동작하는 커맨드가 의미 있는 경우도 있다.
훅 전달 보장
훅 전달은 한 번 이상 으로 의도되어 있는데,
이는 PostStart 또는 PreStop와 같은 특정 이벤트에 대해서,
훅이 여러 번 호출될 수 있다는 것을 의미한다.
이것을 올바르게 처리하는 것은 훅의 구현에 달려 있다.
일반적으로, 전달은 단 한 번만 이루어진다.
예를 들어, HTTP 훅 수신기가 다운되어 트래픽을 받을 수 없는 경우에도,
재전송을 시도하지 않는다.
그러나, 드문 경우로, 이중 전달이 발생할 수 있다.
예를 들어, 훅을 전송하는 도중에 kubelet이 재시작된다면,
Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
디버깅 훅 핸들러
훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다.
만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다.
PostStart의 경우, 이것은 FailedPostStartHook 이벤트이며,
PreStop의 경우, 이것은 FailedPreStopHook 이벤트이다.
이 이벤트는 kubectl describe pod <파드_이름>를 실행하면 볼 수 있다.
다음은 이 커맨드 실행을 통한 이벤트 출력의 몇 가지 예다.
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 파드와, 이를 실행하는 데 도움이 되는 하이-레벨(higher-level) 추상화
워크로드는 쿠버네티스에서 구동되는 애플리케이션이다.
워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의
파드 집합 내에서 실행한다.
쿠버네티스에서 Pod 는 클러스터에서 실행 중인 컨테이너
집합을 나타낸다.
쿠버네티스 파드에는 정의된 라이프사이클이 있다.
예를 들어, 일단 파드가 클러스터에서 실행되고 나서
해당 파드가 동작 중인 노드에
심각한 오류가 발생하면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
최종(final)으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관 없이 Pod 를 새로 생성해야 한다.
그러나, 작업이 훨씬 쉽도록, 각 Pod 를 직접 관리할 필요는 없도록 만들었다.
대신, 사용자를 대신하여 파드 집합을 관리하는 워크로드 리소스 를 사용할 수 있다.
이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이
실행되고 있는지 확인하는 컨트롤러를
구성한다.
StatefulSet는
어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가
데이터를 지속적으로 기록하는 경우, 사용자는 Pod 와
PersistentVolume을 연계하는 StatefulSet 을 실행할 수 있다.
전체적인 회복력 향상을 위해서, StatefulSet 의 Pods 에서 동작 중인 코드는 동일한 StatefulSet 의
다른 Pods 로 데이터를 복제할 수 있다.
DaemonSet은 노드-로컬 기능(node-local facilities)을 제공하는 Pods 를 정의한다.
이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다.
예를 들면, 네트워킹 지원 도구 또는
add-on 등이 있다.
DaemonSet 의 명세에 맞는 노드를 클러스터에 추가할 때마다,
컨트롤 플레인은 해당 신규 노드에 DaemonSet 을 위한 Pod 를 스케줄한다.
Job 및
CronJob은
실행 완료 후 중단되는 작업을 정의한다. CronJobs 이 스케줄에 따라 반복되는 반면,
잡은 단 한 번의 작업을 나타낸다.
더 넓은 쿠버네티스 에코시스템 내에서는 추가적인 동작을 제공하는 제 3자의 워크로드
리소스도 찾을 수 있다.
커스텀 리소스 데피니션을 사용하면,
쿠버네티스 코어에서 제공하지 않는 특별한 동작을 원하는 경우 제 3자의 워크로드 리소스를
추가할 수 있다. 예를 들어, 사용자 애플리케이션을 위한 Pods 의 그룹을 실행하되
모든 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마도 높은 처리량의 분산 처리를 하는 상황 같은),
사용자는 해당 기능을 제공하는 확장을 구현하거나 설치할 수 있다.
다음 내용
각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
일단 애플리케이션이 실행되면, 인터넷에서 서비스로
사용하거나, 웹 애플리케이션의 경우에만
인그레스(Ingress)를 이용하여 사용할 수 있다.
3.4.1 - 파드
파드(Pod) 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.
파드 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의
컨테이너의 그룹이다. 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는
애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의
애플리케이션 컨테이너가 포함된다.
클라우드가 아닌 콘텍스트에서, 동일한 물리 또는 가상 머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다.
애플리케이션 컨테이너와 마찬가지로, 파드에는
파드 시작 중에 실행되는 초기화 컨테이너가
포함될 수 있다. 클러스터가 제공하는 경우, 디버깅을 위해
임시 컨테이너를
삽입할 수도 있다.
파드란 무엇인가?
참고:도커가 가장 일반적으로
잘 알려진 런타임이지만, 쿠버네티스는 도커보다
컨테이너 런타임을
더 많이 지원하며, 도커의 일부 용어를 사용하면 파드를 설명하는 데 도움이 된다.
파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및
도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다.
파드의 콘텍스트 내에서 개별 애플리케이션은
추가적으로 하위 격리가 적용된다.
도커 개념 측면에서, 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이
있는 도커 컨테이너 그룹과 비슷하다.
단일 컨테이너를 실행하는 파드. "파드 당 하나의 컨테이너" 모델은
가장 일반적인 쿠버네티스 유스케이스이다. 이 경우, 파드를 단일 컨테이너를 둘러싼
래퍼(wrapper)로 생각할 수 있다. 쿠버네티스는 컨테이너를 직접 관리하는 대신
파드를 관리한다.
함께 작동해야 하는 여러 컨테이너를 실행하는 파드. 파드는
밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로
구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는
하나의 결합된 서비스 단위를 형성한다. 예를 들어, 하나의 컨테이너는 공유 볼륨에
저장된 데이터를 퍼블릭에 제공하는 반면, 별도의 사이드카 컨테이너는
해당 파일을 새로 고치거나 업데이트한다.
파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 ID를
단일 단위로 함께 래핑한다.
참고: 단일 파드에서 함께 배치된 또는 함께 관리되는 여러 컨테이너를 그룹화하는 것은
비교적 고급 유스케이스이다. 이 패턴은 컨테이너가 밀접하게 결합된
특정 인스턴스에서만 사용해야 한다.
각 파드는 특정 애플리케이션의 단일 인스턴스를 실행하기 위한 것이다. 더 많은
인스턴스를 실행하여 더 많은 전체 리소스를 제공하기 위해 애플리케이션을
수평적으로 확장하려면, 각 인스턴스에 하나씩, 여러 파드를 사용해야 한다.
쿠버네티스에서는 이를 일반적으로 레플리케이션 이라고 한다.
복제된 파드는 일반적으로 워크로드 리소스와
해당 컨트롤러에 의해 그룹으로 생성되고 관리된다.
쿠버네티스가 워크로드 리소스와 해당 컨트롤러를 사용하여 애플리케이션 스케일링과
자동 복구를 구현하는 방법에 대한 자세한 내용은
파드와 컨트롤러를 참고한다.
파드가 여러 컨테이너를 관리하는 방법
파드는 응집력있는 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너)를
지원하도록 설계되었다. 파드의 컨테이너는 클러스터의 동일한 물리 또는 가상 머신에서
자동으로 같은 위치에 배치되고 함께 스케줄된다. 컨테이너는
리소스와 의존성을 공유하고, 서로 통신하고, 종료 시기와 방법을
조정할 수 있다.
예를 들어, 다음 다이어그램에서와 같이
공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는
별도의 "사이드카" 컨테이너가 있을 수 있다.
일부 파드에는 앱 컨테이너 뿐만 아니라 초기화 컨테이너를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.
파드는 기본적으로 파드에 속한 컨테이너에 네트워킹과 스토리지라는
두 가지 종류의 공유 리소스를 제공한다.
파드 작업
사용자가 쿠버네티스에서 직접 개별 파드를 만드는 경우는 거의 없다. 싱글톤 파드도 마찬가지이다. 이는
파드가 상대적으로 일시적인, 일회용 엔티티로 설계되었기 때문이다. 파드가
생성될 때(사용자가 직접 또는
컨트롤러가 간접적으로), 새 파드는
클러스터의 노드에서 실행되도록 스케줄된다.
파드는 파드 실행이 완료되거나, 파드 오브젝트가 삭제되거나,
리소스 부족으로 인해 파드가 축출 되거나, 노드가 실패할 때까지 해당 노드에 남아있다.
참고: 파드에서 컨테이너를 다시 시작하는 것과 파드를 다시 시작하는 것을 혼동해서는 안된다. 파드는
프로세스가 아니라 컨테이너를 실행하기 위한 환경이다. 파드는
삭제될 때까지 유지된다.
파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한
DNS 서브도메인 이름인지 확인한다.
파드와 컨트롤러
워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는
파드 장애 시 복제 및 롤아웃과 자동 복구를
처리한다. 예를 들어, 노드가 실패하면, 컨트롤러는 해당 노드의 파드가 작동을 중지했음을
인식하고 대체 파드를 생성한다. 스케줄러는
대체 파드를 정상 노드에 배치한다.
파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는
파드에는 직접적인 영향을 주지 않는다. 워크로드 리소스의 파드 템플릿을
변경하는 경우, 해당 리소스는 수정된 템플릿을 사용하는 대체 파드를 생성해야 한다.
예를 들어, 스테이트풀셋 컨트롤러는 실행 중인 파드가 각 스테이트풀셋 오브젝트에 대한 현재
파드 템플릿과 일치하는지 확인한다. 스테이트풀셋을 수정하여 파드 템플릿을
변경하면, 스테이트풀셋이 업데이트된 템플릿을 기반으로 새로운 파드를 생성하기 시작한다.
결국, 모든 이전의 파드가 새로운 파드로 교체되고, 업데이트가 완료된다.
각 워크로드 리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다.
스테이트풀셋에 대해 자세히 알아 보려면,
스테이트풀셋 기본 튜토리얼에서 업데이트 전략을 읽어본다.
노드에서 kubelet은
파드 템플릿과 업데이트에 대한 상세 정보를 직접 관찰하거나 관리하지 않는다. 이러한
상세 내용은 추상화된다. 이러한 추상화와 관심사 분리(separation of concerns)는
시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을
확장할 수 있게 한다.
파드 갱신 및 교체
이전 섹션에서 언급한 바와 같이, 워크로드 리소스의 파드
템플릿이 바뀌면, 컨트롤러는 기존의 파드를 갱신하거나 패치하는 대신
갱신된 템플릿을 기반으로 신규 파드를 생성한다.
쿠버네티스는 사용자가 파드를 직접 관리하는 것을 막지는 않는다.
동작 중인 파드의 필드를 갱신하는 것도 가능하다.
그러나,
patch 및
replace와 같은
파드 갱신 작업에는 다음과 같은 제약이 있다.
파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는
namespace, name, uid, 또는 creationTimestamp 필드를 변경할 수 없다.
그리고 generation 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는
갱신만 허용한다.
metadata.deletionTimestamp 가 설정된 경우,
metadata.finalizers 리스트에 새로운 항목이 추가될 수 없다.
파드 갱신은 spec.containers[*].image, spec.initContainers[*].image,
spec.activeDeadlineSeconds, 또는 spec.tolerations 이외의 필드는
변경하지 않을 것이다. spec.tolerations 에 대해서만 새로운 항목을 추가할 수 있다.
spec.activeDeadlineSeconds 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만
허용한다.
지정되지 않은 필드를 양수로 설정;
필드의 양수를 음수가 아닌 더 작은 숫자로
갱신.
리소스 공유와 통신
파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을
지원한다.
파드 스토리지
파드는 공유 스토리지 볼륨의
집합을 지정할 수 있다. 파드의 모든 컨테이너는
공유 볼륨에 접근할 수 있으므로, 해당 컨테이너가 데이터를 공유할 수
있다. 또한 볼륨은 내부 컨테이너 중 하나를 다시
시작해야 하는 경우 파드의 영구 데이터를 유지하도록 허용한다.
쿠버네티스가 공유 스토리지를 구현하고 파드에서 사용할 수 있도록 하는 방법에 대한
자세한 내용은 스토리지를 참고한다.
파드 네트워킹
각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의
모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를
공유한다. 파드 내부(그때 만 해당)에서, 파드에 속한
컨테이너는 localhost 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가
파드 외부의 엔티티와 통신할 때,
공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다.
파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며,
localhost 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는
POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로
통신할 수도 있다. 다른 파드의 컨테이너는
고유한 IP 주소를 가지며
특별한 구성 없이 IPC로 통신할 수 없다.
다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을
사용하여 통신할 수 있다.
파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된
name 과 동일한 것으로 간주한다. 네트워킹 섹션에 이에 대한
자세한 내용이 있다.
컨테이너에 대한 특권 모드
파드의 모든 컨테이너는 컨테이너 명세의 보안 콘텍스트에 있는 privileged 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다.
참고: 이 설정을 사용하려면 사용자의 컨테이너 런타임이 특권이 있는 컨테이너의 개념을 지원해야 한다.
정적 파드
정적 파드 는 API 서버가
관찰하는 대신 특정 노드의 kubelet 데몬에 의해 직접
관리된다.
대부분의 파드는 컨트롤 플레인(예를 들어,
디플로이먼트)에 의해 관리되고, 정적 파드의
경우, kubelet이 각 정적 파드를 직접 감독한다(실패하면 다시 시작한다).
정적 파드는 항상 특정 노드의 Kubelet 하나에 바인딩된다.
정적 파드의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 것이다. 즉,
kubelet을 사용하여 개별 컨트롤 플레인 컴포넌트를 감독한다.
kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버에서 미러 파드를
생성하려고 한다.
즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
여기에서 제어할 수는 없다는 의미이다.
이 페이지에서는 파드의 라이프사이클을 설명한다. 파드는 정의된 라이프사이클을 따른다.
Pending단계에서 시작해서, 기본 컨테이너 중 적어도 하나
이상이 OK로 시작하면 Running 단계를 통과하고, 그런 다음 파드의 컨테이너가
실패로 종료되었는지 여부에 따라 Succeeded 또는 Failed 단계로 이동한다.
파드가 실행되는 동안, kubelet은 일종의 오류를 처리하기 위해 컨테이너를 다시
시작할 수 있다. 파드 내에서, 쿠버네티스는 다양한 컨테이너
상태를 추적하고 파드를 다시 정상 상태로 만들기 위해 취할 조치를
결정한다.
쿠버네티스 API에서 파드는 명세와 실제 상태를 모두 가진다.
파드 오브젝트의 상태는 일련의 파드 조건으로 구성된다.
사용자의 애플리케이션에 유용한 경우, 파드의 조건 데이터에
사용자 정의 준비성 정보를 삽입할 수도 있다.
파드는 파드의 수명 중 한 번만 스케줄된다.
파드가 노드에 스케줄(할당)되면, 파드는 중지되거나 종료될 때까지
해당 노드에서 실행된다.
파드의 수명
개별 애플리케이션 컨테이너와 마찬가지로, 파드는 비교적
임시(계속 이어지는 것이 아닌) 엔티티로 간주된다. 파드가 생성되고, 고유
ID(UID)가
할당되고, 종료(재시작 정책에 따라) 또는 삭제될 때까지 남아있는 노드에
스케줄된다.
만약 노드가 종료되면, 해당 노드에 스케줄된 파드는
타임아웃 기간 후에 삭제되도록 스케줄된다.
파드는 자체적으로 자가 치유되지 않는다. 파드가
노드에 스케줄된 후에 해당 노드가 실패하면, 파드는 삭제된다. 마찬가지로, 파드는
리소스 부족 또는 노드 유지 관리 작업으로 인해 축출되지 않는다. 쿠버네티스는
컨트롤러라
부르는 하이-레벨 추상화를 사용하여
상대적으로 일회용인 파드 인스턴스를 관리하는 작업을 처리한다.
UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되지 않는다. 대신,
해당 파드는 사용자가 원한다면 이름은 같지만, UID가 다른, 거의 동일한 새 파드로
대체될 수 있다.
볼륨과
같은 어떤 것이 파드와 동일한 수명을 갖는다는 것은,
특정 파드(정확한 UID 포함)가 존재하는 한 그것이 존재함을
의미한다. 어떤 이유로든 해당 파드가 삭제되고, 동일한 대체 파드가
생성되더라도, 관련된 그것(이 예에서는 볼륨)도 폐기되고
새로 생성된다.
Pod diagram
컨테이너 간의 공유 스토리지에 퍼시스턴트 볼륨을 사용하는 웹 서버와
파일 풀러(puller)가 포함된 다중 컨테이너 파드이다.
파드의 단계
파드의 status 필드는
phase 필드를 포함하는
PodStatus 오브젝트로 정의된다.
파드의 phase는 파드가 라이프사이클 중 어느 단계에 해당하는지 표현하는 간단한
고수준의 요약이다. Phase는 컨테이너나 파드의 관측 정보에 대한 포괄적인
롤업이나, 포괄적인 상태 머신을 표현하도록 의도되지는 않았다.
파드 phase 값에서 숫자와 의미는 엄격하게 지켜진다.
여기에 문서화된 내용 이외에는, 파드와 파드에 주어진 phase 값에 대해서
어떤 사항도 가정되어서는 안 된다.
phase에 가능한 값은 다음과 같다.
값
의미
Pending
파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다.
Running
파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다.
Succeeded
파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않을 것이다.
Failed
파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
Unknown
어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다.
참고: 파드가 삭제될 때, 일부 kubectl 커맨드에서 Terminating 이 표시된다.
이 Terminating 상태는 파드의 단계에 해당하지 않는다.
파드에는 그레이스풀하게(gracefully) 종료되도록 기간이 부여되며, 그 기본값은 30초이다.
강제로 파드를 종료하려면 --force 플래그를 설정하면 된다.
노드가 죽거나 클러스터의 나머지와의 연결이 끊어지면, 쿠버네티스는
손실된 노드의 모든 파드의 phase 를 Failed로 설정하는 정책을 적용한다.
컨테이너 상태
전체 파드의 단계뿐 아니라, 쿠버네티스는 파드 내부의
각 컨테이너 상태를 추적한다.
컨테이너 라이프사이클 훅(hook)을
사용하여 컨테이너 라이프사이클의 특정 지점에서 실행할 이벤트를 트리거할 수 있다.
일단 스케줄러가
노드에 파드를 할당하면, kubelet은 컨테이너 런타임을
사용하여 해당 파드에 대한 컨테이너 생성을 시작한다.
표시될 수 있는 세 가지 컨테이너 상태는 Waiting, Running 그리고 Terminated 이다.
파드의 컨테이너 상태를 확인하려면, kubectl describe pod <name-of-pod> 를
사용할 수 있다. 출력 결과는 해당 파드 내의 각 컨테이너 상태가
표시된다.
각 상태에는 특정한 의미가 있다.
Waiting
만약 컨테이너가 Running 또는 Terminated 상태가 아니면, Waiting 상태이다.
Waiting 상태의 컨테이너는 시작을 완료하는 데 필요한
작업(예를 들어, 컨테이너 이미지 레지스트리에서 컨테이너 이미지 가져오거나,
시크릿(Secret) 데이터를 적용하는 작업)을
계속 실행하고 있는 중이다.
kubectl 을 사용하여 컨테이너가 Waiting 인 파드를 쿼리하면, 컨테이너가
해당 상태에 있는 이유를 요약하는 Reason 필드도 표시된다.
Running
Running 상태는 컨테이너가 문제없이 실행되고 있음을 나타낸다. postStart 훅이
구성되어 있었다면, 이미 실행되고 완료되었다. kubectl 을
사용하여 컨테이너가 Running 인 파드를 쿼리하면, 컨테이너가 Running 상태에 진입한 시기에 대한
정보도 볼 수 있다.
Terminated
Terminated 상태의 컨테이너는 실행을 시작한 다음 완료될 때까지
실행되었거나 어떤 이유로 실패했다. kubectl 을 사용하여 컨테이너가 Terminated 인 파드를
쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과
종료 시간이 표시된다.
컨테이너에 구성된 preStop 훅이 있는 경우, 컨테이너가 Terminated 상태에 들어가기 전에
실행된다.
컨테이너 재시작 정책
파드의 spec 에는 restartPolicy 필드가 있다. 사용 가능한 값은 Always, OnFailure 그리고
Never이다. 기본값은 Always이다.
restartPolicy 는 파드의 모든 컨테이너에 적용된다. restartPolicy 는
동일한 노드에서 kubelet에 의한 컨테이너 재시작만을 의미한다. 파드의 컨테이너가
종료된 후, kubelet은 5분으로 제한되는 지수 백오프 지연(10초, 20초, 40초, …)으로
컨테이너를 재시작한다. 컨테이너가 10분 동안 아무런 문제없이 실행되면,
kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한다.
파드의 조건
파드는 하나의 PodStatus를 가지며,
그것은 파드가 통과했거나 통과하지 못한 조건에 대한
PodConditions 배열을 가진다.
Ready: 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드
밸런싱 풀에 추가되어야 한다.
필드 이름
설명
type
이 파드 조건의 이름이다.
status
가능한 값이 "True", "False", 또는 "Unknown"으로, 해당 조건이 적용 가능한지 여부를 나타낸다.
lastProbeTime
파드 조건이 마지막으로 프로브된 시간의 타임스탬프이다.
lastTransitionTime
파드가 한 상태에서 다른 상태로 전환된 마지막 시간에 대한 타임스탬프이다.
reason
조건의 마지막 전환에 대한 이유를 나타내는 기계가 판독 가능한 UpperCamelCase 텍스트이다.
message
마지막 상태 전환에 대한 세부 정보를 나타내는 사람이 읽을 수 있는 메시지이다.
파드의 준비성(readiness)
FEATURE STATE:Kubernetes v1.14 [stable]
애플리케이션은 추가 피드백 또는 신호를 PodStatus: Pod readiness
와 같이 주입할 수 있다. 이를 사용하기 위해, kubelet이 파드의 준비성을 평가하기
위한 추가적인 조건들을 파드의 spec 내 readinessGate 필드를 통해서 지정할 수 있다.
준비성 게이트는 파드에 대한 status.condition 필드의 현재
상태에 따라 결정된다. 만약 쿠버네티스가 status.conditions 필드에서 해당하는
조건을 찾지 못한다면, 그 조건의 상태는
기본 값인 "False"가 된다.
여기 예제가 있다.
kind:Pod...spec:readinessGates:- conditionType:"www.example.com/feature-1"status:conditions:- type:Ready # 내장된 PodCondition이다status:"False"lastProbeTime:nulllastTransitionTime:2018-01-01T00:00:00Z- type:"www.example.com/feature-1"# 추가적인 PodConditionstatus:"False"lastProbeTime:nulllastTransitionTime:2018-01-01T00:00:00ZcontainerStatuses:- containerID:docker://abcd...ready:true...
kubectl patch 명령어는 아직 오브젝트 상태 패치(patching)를 지원하지 않는다.
이러한 status.conditions 을 파드에 설정하려면 애플리케이션과
오퍼레이터의
PATCH 액션을 필요로 한다.
쿠버네티스 클라이언트 라이브러리를
사용해서 파드 준비성에 대한 사용자 지정 파드 조건을 설정하는 코드를 작성할 수 있다.
사용자 지정 조건을 사용하는 파드의 경우, 다음 두 조건이 모두 적용되는
경우에 만 해당 파드가 준비된 것으로 평가된다.
파드 내의 모든 컨테이너들이 준비 상태이다.
readinessGates에 지정된 모든 조건들이 True 이다.
파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 False 이면,
kubelet은 파드의 조건을 ContainerReady 로 설정한다.
컨테이너 프로브(probe)
프로브는
컨테이너에서 kubelet에 의해
주기적으로 수행되는 진단(diagnostic)이다.
진단을 수행하기 위해서,
kubelet은 컨테이너에 의해서 구현된
핸들러를 호출한다.
핸들러에는 다음과 같이 세 가지 타입이 있다.
ExecAction은
컨테이너 내에서 지정된 명령어를 실행한다.
명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
TCPSocketAction은
지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다.
포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다.
HTTPGetAction은
지정한 포트 및 경로에서 컨테이너의 IP주소에
대한 HTTP GET 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면
진단이 성공한 것으로 간주한다.
각 probe는 다음 세 가지 결과 중 하나를 가진다.
Success: 컨테이너가 진단을 통과함.
Failure: 컨테이너가 진단에 실패함.
Unknown: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨.
kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고
그에 반응할 수 있다.
livenessProbe: 컨테이너가 동작 중인지 여부를 나타낸다. 만약
활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는
재시작 정책의 대상이 된다. 만약 컨테이너가
활성 프로브를 제공하지 않는 경우, 기본 상태는 Success이다.
readinessProbe: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는
파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의
초기 지연 이전의 기본 상태는 Failure이다. 만약 컨테이너가 준비성 프로브를
지원하지 않는다면, 기본 상태는 Success이다.
startupProbe: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는
활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고,
컨테이너는 재시작 정책에 따라 처리된다. 컨테이너에 스타트업
프로브가 없는 경우, 기본 상태는 Success이다.
만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한
상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가
반드시 필요한 것은 아니다. 그 경우에는 kubelet이 파드의 restartPolicy에
따라서 올바른 대처를 자동적으로 수행할 것이다.
프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를
지정하고, restartPolicy를 항상(Always) 또는 실패 시(OnFailure)로 지정한다.
언제 준비성 프로브를 사용해야 하는가?
FEATURE STATE:Kubernetes v1.0 [stable]
프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면,
준비성 프로브를 지정하길 바란다. 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해
보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가
트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만
트래픽을 받는다는 뜻이다.
만약 컨테이너가 대량의 데이터, 설정 파일들,
또는 시동 중 마그레이션을 처리해야 한다면, 준비성 프로브를 지정하길 바란다.
만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면,
준비성 프로브를 지정하길 바란다.
준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
참고: 파드가 삭제될 때 요청들을 흘려 보내기(drain) 위해
준비성 프로브가 꼭 필요한 것은 아니다. 삭제 시에, 파드는
프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다.
파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로
남아 있다.
언제 스타트업 프로브를 사용해야 하는가?
FEATURE STATE:Kubernetes v1.20 [stable]
스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는
파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때
프로브를 위한 별도의 구성을 설정하여, 활성 간격보다
긴 시간을 허용할 수 있다.
컨테이너가 보통 initialDelaySeconds + failureThreshold × periodSeconds
이후에 기동된다면, 스타트업 프로브가
활성화 프로브와 같은 엔드포인트를 확인하도록 지정해야 한다.
periodSeconds의 기본값은 10s 이다. 이 때 컨테이너가 활성화 프로브의
기본값 변경 없이 기동되도록 하려면, failureThreshold 를 충분히 높게 설정해주어야
한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다.
파드의 종료
파드는 클러스터의 노드에서 실행되는 프로세스를 나타내므로, 해당 프로세스가
더 이상 필요하지 않을 때 정상적으로 종료되도록 하는 것이 중요하다(KILL
시그널로 갑자기 중지되고 정리할 기회가 없는 것 보다).
디자인 목표는 삭제를 요청하고 프로세스가 종료되는 시기를 알 수
있을 뿐만 아니라, 삭제가 결국 완료되도록 하는 것이다.
사용자가 파드의 삭제를 요청하면, 클러스터는 파드가 강제로 종료되기 전에
의도한 유예 기간을 기록하고 추적한다. 강제 종료 추적이
적용되면, kubelet은 정상
종료를 시도한다.
일반적으로, 컨테이너 런타임은 각 컨테이너의 기본 프로세스에 TERM 신호를
전송한다. 많은 컨테이너 런타임은 컨테이너 이미지에 정의된 STOPSIGNAL 값을 존중하며
TERM 대신 이 값을 보낸다.
일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로
전송되고, 그런 다음 파드는
API 서버로부터 삭제된다. 프로세스가
종료될 때까지 기다리는 동안 kubelet 또는 컨테이너 런타임의 관리 서비스가 다시 시작되면, 클러스터는
전체 원래 유예 기간을 포함하여 처음부터 다시 시도한다.
플로우의 예는 다음과 같다.
이 kubectl 도구를 사용하여 기본 유예 기간(30초)으로 특정 파드를 수동으로
삭제한다.
API 서버의 파드는 유예 기간과 함께 파드가 "dead"로 간주되는
시간으로 업데이트된다.
kubectl describe 를 사용하여 삭제하려는 파드를 확인하면, 해당 파드가 "Terminating"으로
표시된다.
파드가 실행 중인 노드에서, kubelet이 파드가 종료된 것(terminating)으로 표시되었음을
확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료
프로세스를 시작한다.
파드의 컨테이너 중 하나가 preStop훅을 정의한 경우, kubelet은
컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 preStop 훅이
계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을
요청한다.
참고:preStop 훅을 완료하는 데 기본 유예 기간이 허용하는 것보다 오랜 시간이 필요한 경우,
이에 맞게 terminationGracePeriodSeconds 를 수정해야 한다.
kubelet은 컨테이너 런타임을 트리거하여 각 컨테이너 내부의 프로세스 1에 TERM 시그널을
보낸다.
참고: 파드의 컨테이너는 서로 다른 시간에 임의의 순서로 TERM 시그널을
수신한다. 종료 순서가 중요한 경우, preStop 훅을 사용하여 동기화하는 것이 좋다.
kubelet이 정상 종료를 시작하는 동시에, 컨트롤 플레인은
구성된 셀렉터가 있는
서비스를 나타내는
엔드포인트(Endpoint)(그리고, 활성화된 경우, 엔드포인트슬라이스(EndpointSlice)) 오브젝트에서 종료된 파드를 제거한다.
레플리카셋(ReplicaSet)과 기타 워크로드 리소스는
더 이상 종료된 파드를 유효한 서비스 내 복제본으로 취급하지 않는다. 로드 밸런서(서비스 프록시와 같은)가
종료 유예 기간이 시작되는 즉시 엔드포인트 목록에서 파드를 제거하므로 느리게 종료되는
파드는 트래픽을 계속 제공할 수 없다.
유예 기간이 만료되면, kubelet은 강제 종료를 트리거한다. 컨테이너 런타임은
SIGKILL 을 파드의 모든 컨테이너에서 여전히 실행 중인 모든 프로세스로 전송한다.
kubelet은 해당 컨테이너 런타임이 하나를 사용하는 경우 숨겨진 pause 컨테이너도 정리한다.
kubelet은 유예 기간을 0(즉시 삭제)으로 설정하여, API 서버에서 파드 오브젝트의
강제 삭제를 트리거한다.
API 서버가 파드의 API 오브젝트를 삭제하면, 더 이상 클라이언트에서 볼 수 없다.
강제 파드 종료
주의: 강제 삭제는 일부 워크로드와 해당 파드에 대해서 잠재적으로 중단될 수 있다.
기본적으로, 모든 삭제는 30초 이내에는 정상적으로 수행된다. kubectl delete 명령은
기본값을 재정의하고 사용자의 고유한 값을 지정할 수 있는 --grace-period=<seconds> 옵션을
지원한다.
유예 기간을 0 로 강제로 즉시 설정하면 API 서버에서 파드가
삭제된다. 파드가 노드에서 계속 실행 중인 경우, 강제 삭제는 kubelet을 트리거하여
즉시 정리를 시작한다.
참고: 강제 삭제를 수행하려면 --grace-period=0 와 함께 추가 플래그 --force 를 지정해야 한다.
강제 삭제가 수행되면, API 서버는 실행 중인 노드에서
파드가 종료되었다는 kubelet의 확인을 기다리지 않는다.
API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파드를 생성할 수
있다. 노드에서 즉시 종료되도록 설정된 파드는 강제 종료되기 전에
작은 유예 기간이 계속 제공된다.
스테이트풀셋(StatefulSet)의 일부인 파드를 강제 삭제해야 하는 경우,
스테이트풀셋에서 파드를 삭제하기에 대한
태스크 문서를 참고한다.
실패한 파드의 가비지 콜렉션
실패한 파드의 경우, API 오브젝트는 사람이나
컨트롤러 프로세스가
명시적으로 파드를 제거할 때까지 클러스터의 API에 남아 있다.
컨트롤 플레인은 파드 수가 구성된 임계값(kube-controller-manager에서
terminated-pod-gc-threshold 에 의해 결정됨)을 초과할 때 종료된 파드(Succeeded 또는
Failed 단계 포함)를 정리한다.
이렇게 하면 시간이 지남에 따라 파드가 생성되고 종료될 때 리소스 유출이 방지된다.
이 페이지는 초기화 컨테이너에 대한 개요를 제공한다. 초기화 컨테이너는
파드의 앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이며, 앱 이미지에는 없는
유틸리티 또는 설정 스크립트 등을 포함할 수 있다.
초기화 컨테이너는 containers 배열(앱 컨테이너를 기술하는)과 나란히
파드 스펙에 명시할 수 있다.
초기화 컨테이너 이해하기
파드는 앱들을 실행하는 다수의 컨테이너를
포함할 수 있고, 또한 앱 컨테이너 실행 전에 동작되는 하나 이상의
초기화 컨테이너도 포함할 수 있다.
다음의 경우를 제외하면, 초기화 컨테이너는 일반적인 컨테이너와 매우 유사하다.
초기화 컨테이너는 항상 완료를 목표로 실행된다.
각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
만약 파드의 초기화 컨테이너가 실패하면, kubelet은 초기화 컨테이너가 성공할 때까지 반복적으로 재시작한다.
그러나, 만약 파드의 restartPolicy 를 절대 하지 않음(Never)으로 설정하고, 해당 파드를 시작하는 동안 초기화 컨테이너가 실패하면, 쿠버네티스는 전체 파드를 실패한 것으로 처리한다.
컨테이너를 초기화 컨테이너로 지정하기 위해서는,
파드 스펙에 앱 containers 배열과 나란히 initContainers 필드를
컨테이너
타입 오브젝트들의 JSON 배열로서 추가한다.
초기화 컨테이너의 상태는 .status.initContainerStatuses 필드를
통해서 컨테이너 상태 배열로 반환된다
(.status.containerStatuses 필드와 유사하게).
일반적인 컨테이너와의 차이점
초기화 컨테이너는 앱 컨테이너의 리소스 상한(limit), 볼륨, 보안 세팅을 포함한
모든 필드와 기능을 지원한다.
그러나, 초기화 컨테이너를 위한 리소스 요청량과 상한은
리소스에 문서화된 것처럼 다르게 처리된다.
또한, 초기화 컨테이너는 lifecycle, livenessProbe, readinessProbe 또는 startupProbe 를 지원하지 않는다.
왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다.
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, kubelet은 해당 초기화 컨테이너들을
한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다.
모든 초기화 컨테이너들이 실행 완료되었을 때, kubelet은 파드의 애플리케이션 컨테이너들을
초기화하고 평소와 같이 실행한다.
초기화 컨테이너 사용하기
초기화 컨테이너는 앱 컨테이너와는 별도의 이미지를 가지고 있기 때문에, 시동(start-up)에
관련된 코드로서 몇 가지 이점을 가진다.
앱 이미지에는 없는 셋업을 위한 유틸리티 또는 맞춤 코드를 포함할 수 있다.
예를 들어, 셋업 중에 단지 sed, awk, python, 또는 dig와 같은 도구를 사용하기 위해서
다른 이미지로부터(FROM) 새로운 이미지를 만들 필요가 없다.
애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서
공동의 단일 앱 이미지 형태로 빌드될 필요가 없다.
초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 리눅스 네임스페이스를 사용한다.
결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는
시크릿에 접근 권한이 주어질 수 있다.
앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱
컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이
충족될 때까지 앱 컨테이너가 시동되는 것을 막거나 지연시키는 간편한 방법을 제공한다.
초기화 컨테이너는 앱 컨테이너 이미지의 보안성을 떨어뜨릴 수도 있는 유틸리티 혹은 커스텀 코드를 안전하게
실행할 수 있다. 불필요한 툴들을 분리한 채로 유지함으로써 앱 컨테이너 이미지의 공격에 대한
노출을 제한할 수 있다.
초기화 컨테이너들이 완료되는 것과 myapp-pod 파드가 Running 상태로
변경되는 것을 볼 것이다.
kubectl get -f myapp.yaml
출력 결과는 다음과 같다.
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 9m
이 간단한 예제는 사용자만의 초기화 컨테이너를 생성하는데
영감을 줄 것이다. 다음 순서에는 더 자세한 예제의 링크가 있다.
자세한 동작
파드 시작 시에 kubelet은 네트워크와 스토리지가 준비될 때까지
초기화 컨테이너의 실행을 지연시킨다. 그런 다음 kubelet은 파드 사양에
나와있는 순서대로 파드의 초기화 컨테이너를 실행한다.
각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로
종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이
실패된다면, 초기화 컨테이너는 파드의 restartPolicy 에 따라서 재시도 된다. 다만,
파드의 restartPolicy 가 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는
restartPolicy 를 실패 시(OnFailure)로 사용한다.
파드는 모든 초기화 컨테이너가 성공되기 전까지 Ready 될 수 없다. 초기화 컨테이너의 포트는
서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 Pending 상태이지만
Initialized 가 거짓이 되는 조건을 가져야 한다.
사용자는 토폴로지 분배 제약 조건 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
참고: v1.19 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
API 서버와
스케줄러에서
EvenPodsSpread기능 게이트를
활성화해야 한다
필수 구성 요소
노드 레이블
토폴로지 분배 제약 조건은 노드 레이블을 의지해서 각 노드가 속한 토폴로지 도메인(들)을 인식한다. 예를 들어, 노드에 다음과 같은 레이블을 가지고 있을 수 있다. node=node1,zone=us-east-1a,region=us-east-1
다음 레이블이 있고, 4개 노드를 가지는 클러스터가 있다고 가정한다.
NAME STATUS ROLES AGE VERSION LABELS
node1 Ready <none> 4m26s v1.16.0 node=node1,zone=zoneA
node2 Ready <none> 3m58s v1.16.0 node=node2,zone=zoneA
node3 Ready <none> 3m17s v1.16.0 node=node3,zone=zoneB
node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
그러면 클러스터는 논리적으로 다음과 같이 보이게 된다.
graph TB
subgraph "zoneB"
n3(Node3)
n4(Node4)
end
subgraph "zoneA"
n1(Node1)
n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4 k8s;
class zoneA,zoneB cluster;
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 잘-알려진 레이블을 재사용할 수 있다.
파드의 분배 제약 조건
API
API 필드 pod.spec.topologySpreadConstraints 는 다음과 같이 정의된다.
사용자는 하나 또는 다중 topologySpreadConstraint 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다.
maxSkew 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는
파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야
한다. 그 의미는 whenUnsatisfiable 의 값에 따라 다르다.
whenUnsatisfiable 이 "DoNotSchedule"과 같을 때, maxSkew 는
대상 토폴로지에서 일치하는 파드 수와 전역 최솟값 사이에
허용되는 최대 차이이다.
whenUnsatisfiable 이 "ScheduleAnyway"와 같으면, 스케줄러는
왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
topologyKey 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
whenUnsatisfiable 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다.
DoNotSchedule (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다.
ScheduleAnyway 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다.
labelSelector 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 레이블 셀렉터를 참조한다.
사용자는 kubectl explain Pod.spec.topologySpreadConstraints 를 실행해서 이 필드에 대한 자세한 내용을 알 수 있다.
예시: 단수 토폴로지 분배 제약 조건
4개 노드를 가지는 클러스터에 foo:bar 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class zoneA,zoneB cluster;
신규 파드가 기존 파드와 함께 영역에 걸쳐서 균등하게 분배되도록 하려면, 스펙(spec)은 다음과 같이 주어질 수 있다.
topologyKey: zone 는 "zone:<any value>" 레이블 쌍을 가지는 노드에 대해서만 균등한 분배를 적용하는 것을 의미한다. whenUnsatisfiable: DoNotSchedule 은 만약 들어오는 파드가 제약 조건을 만족시키지 못하면 스케줄러에게 pending 상태를 유지하도록 지시한다.
만약 스케줄러가 이 신규 파드를 "zoneA"에 배치하면 파드 분포는 [3, 1]이 되며, 따라서 실제 차이(skew)는 2 (3 - 1)가 되어 maxSkew: 1 를 위반하게 된다. 이 예시에서는 들어오는 파드는 오직 "zoneB"에만 배치할 수 있다.
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
OR
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n3
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
사용자는 파드 스펙을 조정해서 다음과 같은 다양한 요구사항을 충족할 수 있다.
maxSkew 를 "2" 보다 큰 값으로 변경해서 들어오는 파드들이 "zoneA"에도 배치할 수 있도록 한다.
topologyKey 를 "node"로 변경해서 파드가 영역이 아닌, 노드에 걸쳐 고르게 분산할 수 있게 한다. 위의 예시에서 만약 maxSkew 가 "1"로 유지되면 들어오는 파드는 오직 "node4"에만 배치할 수 있다.
whenUnsatisfiable: DoNotSchedule 에서 whenUnsatisfiable: ScheduleAnyway 로 변경하면 들어오는 파드는 항상 다른 스케줄링 API를 충족한다는 가정하에 스케줄할 수 있도록 보장한다. 그러나 일치하는 파드가 적은 토폴로지 도메인에 배치되는 것이 좋다. (이 선호도는 리소스 사용 비율 등과 같은 다른 내부 스케줄링 우선순위와 공동으로 정규화 된다는 것을 알아두자.)
예시: 다중 토폴로지 분배 제약 조건
4개 노드를 가지는 클러스터에 foo:bar 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
사용자는 2개의 TopologySpreadConstraints를 사용해서 영역과 노드에 파드를 분배하는 것을 제어할 수 있다.
이 경우에는, 첫 번째 제약 조건에 부합시키려면, 신규 파드는 오직 "zoneB"에만 배치할 수 있다. 두 번째 제약 조건에서는 신규 파드는 오직 "node4"에만 배치할 수 있다. 그런 다음 두 가지 제약 조건의 결과는 AND 가 되므로, 실행 가능한 유일한 옵션은 "node4"에 배치하는 것이다.
다중 제약 조건은 충돌로 이어질 수 있다. 3개의 노드를 가지는 클러스터 하나가 2개의 영역에 걸쳐 있다고 가정한다.
graph BT
subgraph "zoneB"
p4(Pod) --> n3(Node3)
p5(Pod) --> n3
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n1
p3(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
class zoneA,zoneB cluster;
만약 사용자가 "two-constraints.yaml" 을 이 클러스터에 적용하면, "mypod"가 Pending 상태로 유지되는 것을 알게 된다. 이러한 이유는, 첫 번째 제약 조건을 충족하기 위해 "mypod"는 오직 "zoneB"에만 놓을 수 있다. 두 번째 제약 조건에서는 "mypod"는 오직 "node2"에만 놓을 수 있다. 그러면 "zoneB"와 "node2"의 공동 결과는 아무것도 반환되지 않는다.
이 상황을 극복하기 위해서는 사용자가 maxSkew 의 증가 또는 whenUnsatisfiable: ScheduleAnyway 를 사용하도록 제약 조건 중 하나를 수정할 수 있다.
규칙
여기에 주목할만한 몇 가지 암묵적인 규칙이 있다.
신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
topologySpreadConstraints[*].topologyKey 가 없는 노드는 무시된다. 이것은 다음을 의미한다.
이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다.
신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 {zone-typo: zoneC} 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다.
들어오는 파드의 topologySpreadConstraints[*].labelSelector 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 topologySpreadConstraints[*].labelSelector 가 자체 레이블과 일치하도록 하는 것을 권장한다.
만약 신규 파드에 spec.nodeSelector 또는 spec.affinity.nodeAffinity 가 정의되어 있으면, 일치하지 않는 노드는 무시하게 된다.
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
graph BT
subgraph "zoneC"
n5(Node5)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n5 k8s;
class zoneC cluster;
그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 spec.nodeSelector 도 존중된다.
클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본
토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.
.spec.topologySpreadConstraints 에는 어떠한 제약도 정의되어 있지 않는 경우.
서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
기본 제약 조건은 스케줄링 프로파일에서
PodTopologySpread 플러그인의 일부로 설정할 수 있다.
제약 조건은 labelSelector 가 비어 있어야 한다는 점을 제외하고, 위와 동일한 API로
제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
레플리카셋 또는 스테이트풀셋에서 계산한다.
참고: 기본 스케줄링 제약 조건에 의해 생성된 점수는
SelectorSpread 플러그인에
의해 생성된 점수와 충돌 할 수 있다.
PodTopologySpread 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
이 플러그인을 비활성화 하는 것을 권장한다.
내부 기본 제약
FEATURE STATE:Kubernetes v1.20 [beta]
기본적으로 활성화된 DefaultPodTopologySpread 기능 게이트를 사용하면, 기존
SelectorSpread 플러그인이 비활성화된다.
kube-scheduler는 PodTopologySpread 플러그인 구성에 다음과 같은
기본 토폴로지 제약 조건을 사용한다.
파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교
쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가
더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다.
PodAffinity 는, 사용자가 자격이 충족되는 토폴로지 도메인에
원하는 수의 파드를 얼마든지 채울 수 있다.
PodAntiAffinity 로는, 단일 토폴로지 도메인에
단 하나의 파드만 스케줄 될 수 있다.
더 세밀한 제어를 위해, 토폴로지 분배 제약 조건을 지정하여 다양한 토폴로지 도메인에 파드를
분배해서 고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을
제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
더 자세한 내용은
모티베이션(Motivation)를
참고한다.
위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며,
클러스터 호스팅 공급자에 의해서도 수행된다.
클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지
클러스터 관리자에게 문의하거나 클라우드 공급자에게 문의하고, 배포 문서를 참조해서 확인해야 한다.
만약 자발적인 중단을 일으킬 수 있는 원인이 없다면 Pod Disruption Budget의 생성을 넘길 수 있다.
주의: 모든 자발적인 중단이 Pod Disruption Budget에 연관되는 것은 아니다.
예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget을 무시한다.
고가용성이 필요한 경우 애플리케이션을 복제한다.
(복제된 스테이트리스 및
스테이트풀 애플리케이션에 대해 알아보기.)
복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
(안티-어피니티 이용)
또는 영역 간
(다중 영역 클러스터를 이용한다면)에
애플리케이션을 분산해야 한다.
자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다.
그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다.
예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다.
또한 클러스터(노드) 오토스케일링의 일부 구현에서는
단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
클러스터 관리자 또는 호스팅 공급자는
예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
파드 disruption budgets
FEATURE STATE:Kubernetes v1.5 [beta]
쿠버네티스는 자발적인 중단이 자주 발생하는 경우에도 고 가용성 애플리케이션을
실행하는 데 도움이 되는 기능을 제공한다.
애플리케이션 소유자로써, 사용자는 각 애플리케이션에 대해 PodDisruptionBudget(PDB)을 만들 수 있다.
PDB는 자발적 중단으로
일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다.
예를 들어, 정족수 기반의 애플리케이션이
실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다.
웹 프런트 엔드는 부하를 처리하는 레플리카의 수가
일정 비율 이하로 떨어지지 않도록 보장할 수 있다.
클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신
Eviction API로
불리는 PodDisruptionBudget을 준수하는 도구를 이용해야 한다.
예를 들어, kubectl drain 하위 명령을 사용하면 노드를 서비스 중단으로 표시할 수
있다. kubectl drain 을 실행하면, 도구는 사용자가 서비스를 중단하는 노드의
모든 파드를 축출하려고 한다. kubectl 이 사용자를 대신하여 수행하는
축출 요청은 일시적으로 거부될 수 있으며,
도구는 대상 노드의 모든 파드가 종료되거나
설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다.
PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다.
예를 들어 .spec.replicas: 5 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다.
만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면,
Eviction API는 한 번에 1개(2개의 파드가 아닌)의 파드의 자발적인 중단을 허용한다.
파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며
애플리케이션 컨트롤러(디플로이먼트, 스테이트풀셋 등)를 사용한 것과 같다.
파드의 "의도"하는 수량은 해당 파드를 관리하는 워크로드 리소스의 .spec.replicas 를
기반으로 계산한다. 컨트롤 플레인은 파드의 .metadata.ownerReferences 를 검사하여
소유하는 워크로드 리소스를 발견한다.
애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
그러나 워크로드 리소스(디플로이먼트, 스테이트풀셋과 같은)는
롤링 업데이트 시 PDB의 제한을 받지 않는다. 대신, 애플리케이션 업데이트 중
실패 처리는 특정 워크로드 리소스에 대한 명세에서 구성된다.
Eviction API를 사용하여 파드를 축출하면,
PodSpec의
terminationGracePeriodSeconds 설정을 준수하여 정상적으로 종료됨 상태가 된다.)
PodDisruptionBudget 예시
node-1 부터 node-3 까지 3개의 노드가 있는 클러스터가 있다고 하자.
클러스터에는 여러 애플리케이션을 실행하고 있다.
여러 애플리케이션 중 하나는 pod-a, pod-b, pod-c 로 부르는 3개의 레플리카가 있다. 여기에 pod-x 라고 부르는 PDB와 무관한 파드가 보인다.
초기에 파드는 다음과 같이 배치된다.
node-1
node-2
node-3
pod-a available
pod-b available
pod-c available
pod-x available
전체 3개 파드는 디플로이먼트의 일부분으로
전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다.
예를 들어, 클러스터 관리자가 커널 버그를 수정하기위해 새 커널 버전으로 재부팅하려는 경우를 가정해보자.
클러스터 관리자는 첫째로 node-1 을 kubectl drain 명령어를 사용해서 비우려 한다.
kubectl 은 pod-a 과 pod-x 를 축출하려고 한다. 이는 즉시 성공한다.
두 파드는 동시에 terminating 상태로 진입한다.
이렇게 하면 클러스터는 다음의 상태가 된다.
node-1 draining
node-2
node-3
pod-a terminating
pod-b available
pod-c available
pod-x terminating
디플로이먼트는 한 개의 파드가 중지되는 것을 알게되고, pod-d 라는 대체 파드를 생성한다.
node-1 은 차단되어 있어 다른 노드에 위치한다.
무언가가 pod-x 의 대체 파드로 pod-y 도 생성했다.
(참고: 스테이트풀셋은 pod-0 처럼 불릴, pod-a 를
교체하기 전에 완전히 중지해야 하며, pod-0 로 불리지만, 다른 UID로 생성된다.
그렇지 않으면 이 예시는 스테이트풀셋에도 적용된다.)
이제 클러스터는 다음과 같은 상태이다.
node-1 draining
node-2
node-3
pod-a terminating
pod-b available
pod-c available
pod-x terminating
pod-d starting
pod-y
어느 순간 파드가 종료되고, 클러스터는 다음과 같은 상태가 된다.
node-1 drained
node-2
node-3
pod-b available
pod-c available
pod-d starting
pod-y
이 시점에서 만약 성급한 클러스터 관리자가 node-2 또는 node-3 을
비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고,
PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 pod-d 가 available 상태가 된다.
이제 클러스터는 다음과 같은 상태이다.
node-1 drained
node-2
node-3
pod-b available
pod-c available
pod-d available
pod-y
이제 클러스터 관리자는 node-2 를 비우려고 한다.
drain 커멘드는 pod-b 에서 pod-d 와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다.
drain 커멘드는 pod-b 를 축출하는데 성공했다.
그러나 drain 커멘드가 pod-d 를 축출하려 하는 경우
디플로이먼트에 available 상태의 파드는 1개로 축출이 거부된다.
디플로이먼트는pod-b 를 대체할 pod-e 라는 파드를 생성한다.
클러스터에 pod-e 를 스케줄하기 위한 충분한 리소스가 없기 때문에
드레이닝 명령어는 차단된다.
클러스터는 다음 상태로 끝나게 된다.
node-1 drained
node-2
node-3
no node
pod-b terminating
pod-c available
pod-e pending
pod-d available
pod-y
이 시점에서 클러스터 관리자는
클러스터에 노드를 추가해서 업그레이드를 진행해야 한다.
쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지
다음의 사례를 통해 알 수 있다.
애플리케이션에 필요한 레플리카의 수
인스턴스를 정상적으로 종료하는데 소요되는 시간
새 인스턴스를 시작하는데 소요되는 시간
컨트롤러의 유형
클러스터의 리소스 용량
클러스터 소유자와 애플리케이션 소유자의 역할 분리
보통 클러스터 매니저와 애플리케이션 소유자는
서로에 대한 지식이 부족한 별도의 역할로 생각하는 것이 유용하다.
이와 같은 책임의 분리는
다음의 시나리오에서 타당할 수 있다.
쿠버네티스 클러스터를 공유하는 애플리케이션 팀이 많고, 자연스럽게 역할이 나누어진 경우
타사 도구 또는 타사 서비스를 이용해서
클러스터 관리를 자동화 하는 경우
Pod Disruption Budget은 역할 분리에 따라
역할에 맞는 인터페이스를 제공한다.
만약 조직에 역할 분리에 따른 책임의 분리가 없다면
Pod Disruption Budget을 사용할 필요가 없다.
클러스터에서 중단이 발생할 수 있는 작업을 하는 방법
만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은
중단이 발생할 수 있는 작업을 수행하는 경우 다음과 같은 옵션을 선택한다.
업그레이드 하는 동안 다운타임을 허용한다.
다른 레플리카 클러스터로 장애조치를 한다.
다운타임은 없지만, 노드 사본과
전환 작업을 조정하기 위한 인력 비용이 많이 발생할 수 있다.
PDB를 이용해서 애플리케이션의 중단에 견디도록 작성한다.
다운타임 없음
최소한의 리소스 중복
클러스터 관리의 자동화 확대 적용
내결함성이 있는 애플리케이션의 작성은 까다롭지만
자발적 중단를 허용하는 작업의 대부분은 오토스케일링과
비자발적 중단를 지원하는 작업과 겹친다.
이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 파드 에서
임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시
컨테이너를 사용한다.
경고: 임시 컨테이너는 초기 알파 상태이며,
프로덕션 클러스터에는 적합하지 않다.
쿠버네티스 사용 중단(deprecation) 정책에 따라
이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
임시 컨테이너 이해하기
파드 는 쿠버네티스 애플리케이션의
기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기
때문에, 사용자는 파드가 한번 생성되면, 컨테이너를 추가할 수 없다.
대신, 사용자는 보통 디플로이먼트 를
사용해서 제어하는 방식으로 파드를 삭제하고 교체한다.
그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해
기존 파드의 상태를 검사해야 할 수 있다. 이 경우 사용자는
기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을
실행할 수 있다.
임시 컨테이너는 무엇인가?
임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서
다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서
애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는
일반 컨테이너와 동일한 ContainerSpec 을 사용해서 명시하지만, 많은 필드가
호환되지 않으며 임시 컨테이너에는 허용되지 않는다.
임시 컨테이너는 포트를 가지지 않을 수 있으므로, ports,
livenessProbe, readinessProbe 와 같은 필드는 허용되지 않는다.
임시 컨테이너는 pod.spec 에 직접 추가하는 대신
API에서 특별한 ephemeralcontainers 핸들러를 사용해서 만들어지기 때문에
kubectl edit을 사용해서 임시 컨테이너를 추가할 수 없다.
일반 컨테이너와 마찬가지로, 사용자는 임시 컨테이너를 파드에 추가한
이후에 변경하거나 제거할 수 없다.
임시 컨테이너의 사용
임시 컨테이너는 컨테이너가 충돌 되거나 또는 컨테이너 이미지에
디버깅 도구가 포함되지 않은 이유로 kubectl exec 이 불충분할 때
대화형 문제 해결에 유용하다.
특히, distroless 이미지
를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의
컨테이너 이미지를 배포할 수 있다. distroless 이미지는 셸 또는 어떤 디버깅 도구를
포함하지 않기 때문에, kubectl exec 만으로는 distroless
이미지의 문제 해결이 어렵다.
임시 컨테이너 사용 시 프로세스 네임스페이스
공유를
활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다.
임시 컨테이너를 사용해서 문제를 해결하는 예시는
[임시 디버깅 컨테이너로 디버깅하기]
(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다.
임시 컨테이너 API
참고: 이 섹션의 예시는 EphemeralContainers기능
게이트의
활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
보여준다. 일반적으로 kubectl debug 또는
다른 kubectl플러그인을
사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
임시 컨테이너는 파드의 ephemeralcontainers 하위 리소스를
사용해서 생성되며, kubectl --raw 를 사용해서 보여준다. 먼저
EphemeralContainers 목록으로 추가하는 임시 컨테이너를 명시한다.
디플로이먼트에서 의도하는 상태 를 설명하고, 디플로이먼트 컨트롤러(Controller)는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다.
참고: 디플로이먼트가 소유하는 레플리카셋은 관리하지 말아야 한다. 사용자의 유스케이스가 다음에 포함되지 않는 경우 쿠버네티스 리포지터리에 이슈를 올릴 수 있다.
디플로이먼트의 PodTemplateSpec을 업데이트해서 파드의 새로운 상태를 선언한다. 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로운 레플리카셋으로 속도를 제어하며 이동하는 것을 관리한다. 각각의 새로운 레플리카셋은 디플로이먼트의 수정 버전에 따라 업데이트한다.
만약 디플로이먼트의 현재 상태가 안정적이지 않은 경우 디플로이먼트의 이전 버전으로 롤백한다. 각 롤백은 디플로이먼트의 수정 버전에 따라 업데이트한다.
.metadata.name 필드에 따라 nginx-deployment 이름으로 디플로이먼트가 생성된다.
.spec.replicas 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다.
.spec.selector 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다.
이 사례에서는 파드 템플릿에 정의된 레이블(app: nginx)을 선택한다.
그러나 파드 템플릿 자체의 규칙이 만족되는 한,
보다 정교한 선택 규칙의 적용이 가능하다.
참고:.spec.selector.matchLabels 필드는 {key,value}의 쌍으로 매핑되어있다. matchLabels 에 매핑된
단일 {key,value}은 matchExpressions 의 요소에 해당하며, key 필드는 "key"에 그리고 operator는 "In"에 대응되며
value 배열은 "value"만 포함한다.
매칭을 위해서는 matchLabels 와 matchExpressions 의 모든 요건이 충족되어야 한다.
template 필드에는 다음 하위 필드가 포함되어있다.
파드는 .metadata.labels 필드를 사용해서 app: nginx 라는 레이블을 붙인다.
파드 템플릿의 사양 또는 .template.spec 필드는
파드가 도커 허브의 nginx 1.14.2 버전 이미지를 실행하는
nginx 컨테이너 1개를 실행하는 것을 나타낸다.
컨테이너 1개를 생성하고, .spec.template.spec.containers[0].name 필드를 사용해서 nginx 이름을 붙인다.
시작하기 전에, 쿠버네티스 클러스터가 시작되고 실행 중인지 확인한다.
위의 디플로이먼트를 생성하려면 다음 단계를 따른다.
참고:--record 플래그를 지정해서 실행된 명령을 kubernetes.io/change-cause 리소스 어노테이션에 작성할 수 있다.
기록된 변경사항은 향후 인트로스펙션(introspection)에 유용하다. 예를 들면, 디플로이먼트의 각 수정 버전에서 실행된 명령을 볼 수 있다.
kubectl get deployments 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다.
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
클러스터에서 디플로이먼트를 점검할 때, 다음 필드가 표시된다.
NAME 은 네임스페이스에 있는 디플로이먼트 이름의 목록이다.
READY 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다. ready/desired 패턴을 따른다.
UP-TO-DATE 는 의도한 상태를 얻기 위해 업데이트된 레플리카의 수를 표시한다.
AVAILABLE 은 사용자가 사용할 수 있는 애플리케이션 레플리카의 수를 표시한다.
AGE 는 애플리케이션의 실행된 시간을 표시한다.
.spec.replicas 필드에 따라 의도한 레플리카의 수가 3개인지 알 수 있다.
디플로이먼트의 롤아웃 상태를 보려면, kubectl rollout status deployment/nginx-deployment 를 실행한다.
다음과 유사하게 출력된다.
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out
몇 초 후 kubectl get deployments 를 다시 실행한다.
다음과 유사하게 출력된다.
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다.
디플로이먼트로 생성된 레플리카셋(rs)을 보려면, kubectl get rs 를 실행한다. 다음과 유사하게 출력된다.
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
레플리카셋의 출력에는 다음 필드가 표시된다.
NAME 은 네임스페이스에 있는 레플리카셋 이름의 목록이다.
DESIRED 는 디플로이먼트의 생성 시 정의된 의도한 애플리케이션 레플리카 의 수를 표시한다. 이것이 의도한 상태 이다.
CURRENT 는 현재 실행 중인 레플리카의 수를 표시한다.
READY 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다.
AGE 는 애플리케이션의 실행된 시간을 표시한다.
레플리카셋의 이름은 항상 [DEPLOYMENT-NAME]-[RANDOM-STRING] 형식으로 된 것을 알 수 있다. 무작위 문자열은
무작위로 생성되며, pod-template-hash 를 시드(seed)로 사용한다.
각 파드에 자동으로 생성된 레이블을 보려면, kubectl get pods --show-labels 를 실행한다.
다음과 유사하게 출력된다.
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
만들어진 레플리카셋은 실행 중인 3개의 nginx 파드를 보장한다.
참고:
디플로이먼트에는 파드 템플릿 레이블과 적절한 셀렉터를 반드시 명시해야 한다
(이 예시에서는 app: nginx).
레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀셋(StatefulSet) 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다.
Pod-template-hash 레이블
주의: 이 레이블은 변경하면 안 된다.
pod-template-hash 레이블은 디플로이먼트 컨트롤러에 의해서 디플로이먼트가 생성 또는 채택한 모든 레플리카셋에 추가된다.
이 레이블은 디플로이먼트의 자식 레플리카셋이 겹치지 않도록 보장한다. 레플리카셋의 PodTemplate 을 해싱하고, 해시 결과를 레플리카셋 셀렉터,
파드 템플릿 레이블 및 레플리카셋 이 가질 수 있는 기존의 모든 파드에 레이블 값으로 추가해서 사용하도록 생성한다.
디플로이먼트 업데이트
참고: 디플로이먼트의 파드 템플릿(즉, .spec.template)이 변경된 경우에만 디플로이먼트의 롤아웃이 트리거(trigger) 된다.
예를 들면 템플릿의 레이블이나 컨테이너 이미지가 업데이트된 경우이다. 디플로이먼트의 스케일링과 같은 다른 업데이트는 롤아웃을 트리거하지 말아야 한다.
다음 단계에 따라 디플로이먼트를 업데이트한다.
nginx:1.14.2 이미지 대신 nginx:1.16.1 이미지를 사용하도록 nginx 파드를 업데이트 한다.
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
또는 다음의 명령어를 사용한다.
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
다음과 유사하게 출력된다.
deployment.apps/nginx-deployment image updated
대안으로 디플로이먼트를 edit 해서 .spec.template.spec.containers[0].image 를 nginx:1.14.2 에서 nginx:1.16.1 로 변경한다.
kubectl edit deployment.v1.apps/nginx-deployment
다음과 유사하게 출력된다.
deployment.apps/nginx-deployment edited
롤아웃 상태를 보려면 다음을 실행한다.
kubectl rollout status deployment/nginx-deployment
이와 유사하게 출력된다.
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
또는
deployment "nginx-deployment" successfully rolled out
업데이트된 디플로이먼트에 대해 자세한 정보 보기
롤아웃이 성공하면 kubectl get deployments 를 실행해서 디플로이먼트를 볼 수 있다.
이와 유사하게 출력된다.
NAME READY UP-TO-DATE AVAILABLE AGEnginx-deployment 3/3 3 3 36s
kubectl get rs 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고,
새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다.
kubectl get rs
이와 유사하게 출력된다.
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 6s
nginx-deployment-2035384211 0 0 0 36s
get pods 를 실행하면 새 파드만 표시된다.
kubectl get pods
이와 유사하게 출력된다.
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-khku8 1/1 Running 0 14s
nginx-deployment-1564180365-nacti 1/1 Running 0 14s
nginx-deployment-1564180365-z9gth 1/1 Running 0 14s
다음에 이러한 파드를 업데이트 하려면 디플로이먼트의 파드 템플릿만 다시 업데이트 하면 된다.
디플로이먼트는 업데이트되는 동안 일정한 수의 파드만 중단되도록 보장한다. 기본적으로
적어도 의도한 파드 수의 75% 이상이 동작하도록 보장한다(최대 25% 불가).
또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다.
기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).
예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음
이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며,
충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다.
이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다.
디플로이먼트의 세부 정보 가져오기
kubectl describe deployments
이와 유사하게 출력된다.
Name: nginx-deployment
Namespace: default
CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=2
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.16.1
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3
Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1
Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2
Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2
Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1
Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3
Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서
3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다.
디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음
이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다.
이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다.
마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다.
롤오버(일명 인-플라이트 다중 업데이트)
디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이
의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서
.spec.selector 레이블과 일치하는 파드를 컨트롤 하지만, 템플릿과 .spec.template 이 불일치하면 스케일 다운이 된다.
결국 새로운 레플리카셋은 .spec.replicas 로 스케일되고, 모든 기존 레플리카셋은 0개로 스케일된다.
만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고,
스케일 업하기 시작한다. 그리고 이전에 스케일 업 하던 레플리카셋에 롤오버 한다.
--이것은 기존 레플리카셋 목록에 추가하고 스케일 다운을 할 것이다.
예를 들어 디플로이먼트로 nginx:1.14.2 레플리카를 5개 생성을 한다.
하지만 nginx:1.14.2 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 nginx:1.16.1
레플리카 5개를 생성성하도록 업데이트를 한다고 가정한다. 이 경우 디플로이먼트는 즉시 생성된 3개의
nginx:1.14.2 파드 3개를 죽이기 시작하고 nginx:1.16.1 파드를 생성하기 시작한다.
이것은 과정이 변경되기 전 nginx:1.14.2 레플리카 5개가
생성되는 것을 기다리지 않는다.
레이블 셀렉터 업데이트
일반적으로 레이블 셀렉터를 업데이트 하는 것을 권장하지 않으며 셀렉터를 미리 계획하는 것을 권장한다.
어떤 경우든 레이블 셀렉터의 업데이트를 해야하는 경우 매우 주의하고,
모든 영향을 파악했는지 확인해야 한다.
참고: API 버전 apps/v1 에서 디플로이먼트의 레이블 셀렉터는 생성 이후에는 변경할 수 없다.
셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트해야 한다.
그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가
이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며,
새로운 레플리카셋을 생성하게 된다.
셀렉터 업데이트는 기존 셀렉터 키 값을 변경하며, 결과적으로 추가와 동일한 동작을 한다.
셀렉터 삭제는 디플로이먼트 셀렉터의 기존 키를 삭제하며 파드 템플릿 레이블의 변경을 필요로 하지 않는다.
기존 레플리카셋은 고아가 아니고, 새 레플리카셋은 생성되지 않는다.
그러나 제거된 레이블은 기존 파드와 레플리카셋에 여전히 존재한다는 점을 참고해야 한다.
디플로이먼트 롤백
때때로 디플로이먼트의 롤백을 원할 수도 있다. 예를 들어 디플로이먼트가 지속적인 충돌로 안정적이지 않은 경우.
기본적으로 모든 디플로이먼트의 롤아웃 기록은 시스템에 남아있어 언제든지 원할 때 롤백이 가능하다
(이 사항은 수정 기록에 대한 상한 수정을 통해서 변경할 수 있다).
참고: 디플로이먼트의 수정 버전은 디플로이먼트 롤아웃시 생성된다. 이는 디플로이먼트 파드 템플릿
(.spec.template)이 변경되는 경우에만 새로운 수정 버전이 생성된다는 것을 의미한다.
예를 들어 템플릿의 레이블 또는 컨테이너 이미지를 업데이트 하는 경우.
디플로이먼트의 스케일링과 같은 다른 업데이트시 디플로이먼트 수정 버전은 생성되지 않으며 수동-스케일링 또는 자동-스케일링을 동시에 수행할 수 있다.
이는 이전 수정 버전으로 롤백을 하는 경우에 디플로이먼트 파드 템플릿 부분만
롤백된다는 것을 의미한다.
디플로이먼트를 업데이트하는 동안 이미지 이름을 nginx:1.16.1 이 아닌 nginx:1.161 로 입력해서 오타를 냈다고 가정한다.
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
이와 유사하게 출력된다.
deployment.apps/nginx-deployment image updated
롤아웃이 고착 된다. 고착된 롤아웃 상태를 확인할 수 있다.
kubectl rollout status deployment/nginx-deployment
이와 유사하게 출력된다.
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
Ctrl-C 를 눌러 위의 롤아웃 상태 보기를 중지한다. 고착된 롤아웃 상태에 대한 자세한 정보는 이 것을 더 읽어본다.
이전 레플리카는 2개(nginx-deployment-1564180365 과 nginx-deployment-2035384211), 새 레플리카는 1개(nginx-deployment-3066724191)임을 알 수 있다.
kubectl get rs
이와 유사하게 출력된다.
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 25s
nginx-deployment-2035384211 0 0 0 36s
nginx-deployment-3066724191 1 1 0 6s
생성된 파드를 보면, 새로운 레플리카셋에 생성된 1개의 파드가 이미지 풀 루프(pull loop)에서 고착된 것을 볼 수 있다.
kubectl get pods
이와 유사하게 출력된다.
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae 1/1 Running 0 25s
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
nginx-deployment-1564180365-hysrc 1/1 Running 0 25s
nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
참고: 디플로이먼트 컨트롤러가 잘못된 롤아웃을 자동으로 중지하고, 새로운 레플리카셋의 스케일 업을 중지한다. 이는 지정한 롤링 업데이트의 파라미터(구체적으로 maxUnavailable)에 따라 달라진다. 쿠버네티스는 기본값으로 25%를 설정한다.
디플로이먼트에 대한 설명 보기
kubectl describe deployment
이와 유사하게 출력된다.
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
Labels: app=nginx
Selector: app=nginx
Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.161
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True ReplicaSetUpdated
OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created)
NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created)
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
이 문제를 해결하려면 디플로이먼트를 안정적인 이전 수정 버전으로 롤백해야 한다.
디플로이먼트의 롤아웃 기록 확인
다음 순서에 따라 롤아웃 기록을 확인한다.
먼저 이 디플로이먼트의 수정 사항을 확인한다.
kubectl rollout history deployment.v1.apps/nginx-deployment
이제 디플로이먼트가 이전 안정 수정 버전으로 롤백 된다. 버전 2로 롤백하기 위해 DeploymentRollback 이벤트가
디플로이먼트 컨트롤러에서 생성되는 것을 볼 수 있다.
만약 롤백에 성공하고, 디플로이먼트가 예상대로 실행되는지 확인하려면 다음을 실행한다.
kubectl get deployment nginx-deployment
이와 유사하게 출력된다.
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 30m
디플로이먼트의 설명 가져오기.
kubectl describe deployment nginx-deployment
이와 유사하게 출력된다.
Name: nginx-deployment
Namespace: default
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=4
kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.16.1
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1
Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2
Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3
Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0
Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1
Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2
Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0
디플로이먼트 롤링업데이트는 여러 버전의 애플리케이션을 동시에 실행할 수 있도록 지원한다.
사용자 또는 오토스케일러가 롤아웃 중에 있는 디플로이먼트 롤링 업데이트를 스케일링 하는 경우(진행중 또는 일시 중지 중),
디플로이먼트 컨트롤러는 위험을 줄이기 위해 기존 활성화된 레플리카셋(파드와 레플리카셋)의 추가 레플리카의 균형을 조절 한다.
이것을 proportional scaling 라 부른다.
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 10 10 10 10 50s
클러스터 내부에서 확인할 수 없는 새 이미지로 업데이트 된다.
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
이와 유사하게 출력된다.
deployment.apps/nginx-deployment image updated
이미지 업데이트는 레플리카셋 nginx-deployment-1989198191 으로 새로운 롤 아웃이 시작하지만,
위에서 언급한 maxUnavailable 의 요구 사항으로 인해 차단된다. 롤아웃 상태를 확인한다.
kubectl get rs
이와 유사하게 출력된다.
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 5 5 0 9s
nginx-deployment-618515232 8 8 8 1m
그 다음 디플로이먼트에 대한 새로운 스케일링 요청이 함께 따라온다. 오토스케일러는 디플로이먼트 레플리카를 15로 증가시킨다.
디플로이먼트 컨트롤러는 새로운 5개의 레플리카의 추가를 위한 위치를 결정해야 한다.
만약 비례적 스케일링을 사용하지 않으면 5개 모두 새 레플리카셋에 추가된다.
비례적 스케일링으로 추가 레플리카를 모든 레플리카셋에 걸쳐 분산할 수 있다.
비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카셋으로 이동한다.
남은 것들은 대부분의 레플리카가 있는 레플리카셋에 추가된다. 0개의 레플리카가 있는 레플리카셋은 스케일 업 되지 않는다.
위의 예시에서 기존 레플리카셋에 3개의 레플리카가 추가되고, 2개의 레플리카는 새 레플리카에 추가된다.
결국 롤아웃 프로세스는 새 레플리카가 정상이라고 가정하면 모든 레플리카를 새 레플리카셋으로 이동시킨다.
이를 확인하려면 다음을 실행한다.
kubectl get deploy
이와 유사하게 출력된다.
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 15 18 7 8 7m
롤아웃 상태는 레플리카가 각 레플리카셋에 어떻게 추가되었는지 확인한다.
kubectl get rs
이와 유사하게 출력된다.
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
디플로이먼트의 일시 중지와 재개
하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다.
이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
예를 들어, 생성된 디플로이먼트의 경우
디플로이먼트 상세 정보를 가져온다.
kubectl get deploy
이와 유사하게 출력된다.
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 1m
롤아웃 상태를 가져온다.
kubectl get rs
이와 유사하게 출력된다.
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 1m
kubectl rollout status 를 사용해서 디플로이먼트의 진행사황을 모니터할 수 있다.
디플로이먼트 완료
쿠버네티스는 다음과 같은 특성을 가지게 되면 디플로이먼트를 완료 로 표시한다.
디플로이먼트과 관련된 모든 레플리카가 지정된 최신 버전으로 업데이트 되었을 때.
즉, 요청한 모든 업데이트가 완료되었을 때.
디플로이먼트와 관련한 모든 레플리카를 사용할 수 있을 때.
디플로이먼트에 대해 이전 복제본이 실행되고 있지 않을 때.
kubectl rollout status 를 사용해서 디플로이먼트가 완료되었는지 확인할 수 있다.
만약 롤아웃이 성공적으로 완료되면 kubectl rollout status 는 종료 코드로 0이 반환된다.
kubectl rollout status deployment/nginx-deployment
이와 유사하게 출력된다.
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx-deployment" successfully rolled out
그리고 kubectl rollout 의 종료 상태는 0(success)이다.
echo$?
0
디플로이먼트 실패
디플로이먼트시 새 레플리카셋인 완료되지 않은 상태에서는 배포를 시도하면 고착될 수 있다.
이 문제는 다음 몇 가지 요인으로 인해 발생한다.
할당량 부족
준비성 프로브(readiness probe)의 실패
이미지 풀 에러
권한 부족
범위 제한
애플리케이션 런타임의 잘못된 구성
이 조건을 찾을 수 있는 한 가지 방법은 디플로이먼트 스펙에서 데드라인 파라미터를 지정하는 것이다
(.spec.progressDeadlineSeconds). .spec.progressDeadlineSeconds 는
(디플로이먼트 상태에서) 디플로이먼트의 진행이 정지되었음을 나타내는 디플로이먼트 컨트롤러가
대기하는 시간(초)를 나타낸다.
다음 kubectl 명령어로 progressDeadlineSeconds 를 설정해서 컨트롤러가
10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.
참고: 쿠버네티스는 Reason=ProgressDeadlineExceeded 과 같은 상태 조건을
보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며,
예를 들어 디플로이먼트를 이전 버전으로 롤백할 수 있다.
참고: 만약 디플로이먼트를 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다.
롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고
재개할 수 있다.
설정한 타임아웃이 낮거나 일시적으로 처리될 수 있는 다른 종료의 에러로 인해 디플로이먼트에 일시적인 에러가 발생할 수 있다.
예를 들어, 할당량이 부족하다고 가정해보자.
만약 디플로이먼트를 설명하려면 다음 섹션을 확인한다.
kubectl describe deployment nginx-deployment
이와 유사하게 출력된다.
<...>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True ReplicaSetUpdated
ReplicaFailure True FailedCreate
<...>
만약 kubectl get deployment nginx-deployment -o yaml 을 실행하면 디플로이먼트 상태는 다음과 유사하다.
결국, 디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의
상태와 이유를 업데이트한다.
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing False ProgressDeadlineExceeded
ReplicaFailure True FailedCreate
디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나,
네임스페이스에서 할당량을 늘려서 할당량이 부족한 문제를 해결할 수 있다.
만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면
성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(Status=True 와 Reason=NewReplicaSetAvailable).
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
Type=Available 과 Status=True 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다.
최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. Type=Progressing 과 Status=True 는 디플로이먼트가
롤아웃 도중에 진행 중 이거나, 성공적으로 완료되었으며, 진행 중 최소한으로 필요한 새로운 레플리카를 이용 가능하다는 것이다.
(자세한 내용은 특정 조건의 이유를 참조한다.
이 경우 Reason=NewReplicaSetAvailable 는 배포가 완료되었음을 의미한다.)
kubectl rollout status 를 사용해서 디플로이먼트의 진행이 실패되었는지 확인할 수 있다.
kubectl rollout status 는 디플로이먼트의 진행 데드라인을 초과하면 0이 아닌 종료 코드를 반환한다.
kubectl rollout status deployment.v1.apps/nginx-deployment
이와 유사하게 출력된다.
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
그리고 kubectl rollout 의 종료 상태는 1(error를 의미함)이다.
echo$?
1
실패한 디플로이먼트에서의 운영
완료된 디플로이먼트에 적용되는 모든 행동은 실패한 디플로이먼트에도 적용된다.
디플로이먼트 파드 템플릿에서 여러 개의 수정사항을 적용해야하는 경우 스케일 업/다운 하거나, 이전 수정 버전으로 롤백하거나, 일시 중지할 수 있다.
정책 초기화
디플로이먼트의 .spec.revisionHistoryLimit 필드를 설정해서
디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다.
기본적으로 10으로 되어있다.
참고: 명시적으로 이 필드를 0으로 설정하면 그 결과로 디플로이먼트의 기록을 전부 초기화를 하고,
디플로이먼트는 롤백할 수 없게 된다.
카나리 디플로이먼트
만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리스를 롤아웃 하기 위해서는
리소스 관리에
설명된 카나리 패던에 따라 각 릴리스 마다 하나씩 여러 디플로이먼트를 생성할 수 있다.
디플로이먼트 사양 작성
다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 .apiVersion, .kind 그리고 .metadata 필드가 필요하다.
설정 파일 작업에 대한 일반적인 내용은
애플리케이션 배포하기,
컨테이너 구성하기 그리고 kubectl을 사용해서 리소스 관리하기 문서를 참조한다.
디플로이먼트 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
.spec.replicas 은 필요한 파드의 수를 지정하는 선택적 필드이다. 이것의 기본값은 1이다.
셀렉터
.spec.selector 는 디플로이먼트의 대상이 되는 파드에 대해 레이블 셀렉터를
지정하는 필수 필드이다.
.spec.selector 는 .spec.template.metadata.labels 과 일치해야 하며, 그렇지 않으면 API에 의해 거부된다.
API 버전 apps/v1 에서는 .spec.selector 와 .metadata.labels 이 설정되지 않으면 .spec.template.metadata.labels 은 기본 설정되지 않는다. 그래서 이것들은 명시적으로 설정되어야 한다. 또한 apps/v1 에서는 디플로이먼트를 생성한 후에는 .spec.selector 이 변경되지 않는 점을 참고한다.
디플로이먼트는 템플릿의 .spec.template 와 다르거나 파드의 수가 .spec.replicas 를 초과할 경우
셀렉터와 일치하는 레이블을 가진 파드를 종료할 수 있다.
파드의 수가 의도한 수량보다 적을 경우 .spec.template 에 맞는 새 파드를 띄운다.
참고: 다른 디플로이먼트를 생성하거나, 레플리카셋 또는 레플리케이션컨트롤러와 같은 다른 컨트롤러를 사용해서 직접적으로 레이블과 셀렉터가 일치하는 다른 파드를 생성하지 말아야 한다.
만약 이렇게 하면 첫 번째 디플로이먼트는 다른 파드를 만들었다고 생각한다.
쿠버네티스는 이 일을 막지 않는다.
만약 셀렉터가 겹치는 컨트롤러가 어러 개 있는 경우, 컨트롤러는 서로 싸우고
올바르게 작동하지 않는다.
전략
.spec.strategy 는 이전 파드를 새로운 파드로 대체하는 전략을 명시한다.
.spec.strategy.type 은 "재생성" 또는 "롤링업데이트"가 될 수 있다.
"롤링업데이트"가 기본값이다.
디플로이먼트 재생성
기존의 모든 파드는 .spec.strategy.type==Recreate 이면 새 파드가 생성되기 전에 죽는다.
참고: 이렇게 하면 업그레이드를 생성하기 전에 파드 종료를 보장할 수 있다. 디플로이먼트를 업그레이드하면,
이전 버전의 모든 파드가 즉시 종료된다. 신규 버전의 파드가 생성되기 전에 성공적으로 제거가
완료되기를 대기한다. 파드를 수동으로 삭제하면, 라이프사이클은 레플리카셋에 의해
제어되며(이전 파드가 여전히 종료 상태에 있는 경우에도) 교체용 파드가 즉시 생성된다. 파드에
대해 "최대" 보장이 필요한 경우
스테이트풀셋의 사용을 고려해야 한다.
디플로이먼트 롤링 업데이트
디플로이먼트는 .spec.strategy.type==RollingUpdate 이면 파드를 롤링 업데이트
방식으로 업데이트 한다. maxUnavailable 와 maxSurge 를 명시해서
롤링 업데이트 프로세스를 제어할 수 있다.
최대 불가(Max Unavailable)
.spec.strategy.rollingUpdate.maxUnavailable 은 업데이트 프로세스 중에 사용할 수 없는 최대 파드의 수를 지정하는 선택적 필드이다.
이 값은 절대 숫자(예: 5) 또는 의도한 파드 비율(예: 10%)이 될 수 있다.
절대 값은 반올림해서 백분율로 계산한다.
만약 .spec.strategy.rollingUpdate.maxSurge 가 0이면 값이 0이 될 수 없다. 기본 값은 25% 이다.
예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를
의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며,
업데이트 중에 항상 사용 가능한 전체 파드의 수는
의도한 파드의 수의 70% 이상이 되도록 새 레플리카셋을 스케일 업할 수 있다.
최대 서지(Max Surge)
.spec.strategy.rollingUpdate.maxSurge 는 의도한 파드의 수에 대해 생성할 수 있는 최대 파드의 수를 지정하는 선택적 필드이다.
이 값은 절대 숫자(예: 5) 또는 의도한 파드 비율(예: 10%)이 될 수 있다.
MaxUnavailable 값이 0이면 이 값은 0이 될 수 없다.
절대 값은 반올림해서 백분율로 계산한다. 기본 값은 25% 이다.
예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 새 레플리카셋의 크기를 즉시 조정해서
기존 및 새 파드의 전체 갯수를 의도한 파드의 130%를 넘지 않도록 한다.
기존 파드가 죽으면 새로운 래플리카셋은 스케일 업할 수 있으며,
업데이트하는 동안 항상 실행하는 총 파드의 수는 최대 의도한 파드의 수의 130%가 되도록 보장한다.
진행 기한 시간(초)
.spec.progressDeadlineSeconds 는 디플로어먼트가 표면적으로 Type=Progressing, Status=False의
상태 그리고 리소스가 Reason=ProgressDeadlineExceeded 상태로 진행 실패를 보고하기 전에
디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다.
디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. 기본값은 600(초)이다.
미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고,
그 즉시 디플로이먼트를 롤백할 것이다.
만약 명시된다면 이 필드는 .spec.minReadySeconds 보다 커야 한다.
최소 대기 시간(초)
.spec.minReadySeconds 는 새롭게 생성된 파드의 컨테이너가 어떤 것과도 충돌하지 않고 사
용할 수 있도록 준비되어야 하는 최소 시간(초)을 지정하는 선택적 필드이다.
이 기본 값은 0이다(파드는 준비되는 즉시 사용할 수 있는 것으로 간주됨).
파드가 준비되었다고 간주되는 시기에 대한 자세한 내용은 컨테이너 프로브를 참조한다.
수정 버전 기록 제한
디플로이먼트의 수정 버전 기록은 자신이 컨트롤하는 레플리카셋에 저장된다.
.spec.revisionHistoryLimit 은 롤백을 허용하기 위해 보존할 이전 레플리카셋의 수를 지정하는 선택적 필드이다.
이 이전 레플리카셋은 etcd 의 리소스를 소비하고, kubectl get rs 의 결과를 가득차게 만든다. 각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다. 기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다.
더욱 구체적으로 이 필드를 0으로 설정하면 레플리카가 0이 되며 이전 레플리카셋이 정리된다.
이 경우, 새로운 디플로이먼트 롤아웃을 취소할 수 없다. 새로운 디플로이먼트 롤아웃은 수정 버전 이력이 정리되기 때문이다.
일시 정지
.spec.paused 는 디플로이먼트를 일시 중지나 재개하기 위한 선택적 부울 필드이다.
일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은
일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다.
디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다.
3.4.2.2 - 레플리카셋
레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다.
이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다.
레플리카셋의 작동 방식
레플리카셋을 정의하는 필드는 획득 가능한 파드를 식별하는 방법이 명시된 셀렉터, 유지해야 하는 파드 개수를 명시하는 레플리카의 개수,
그리고 레플리카 수 유지를 위해 생성하는 신규 파드에 대한 데이터를 명시하는 파드 템플릿을 포함한다.
그러면 레플리카셋은 필드에 지정된 설정을 충족하기 위해 필요한 만큼 파드를 만들고 삭제한다.
레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을
사용한다.
레플리카셋은 파드의 metadata.ownerReferences
필드를 통해 파드에 연결되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다.
레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
레플리카셋은 셀렉터를 이용해서 필요한 새 파드를 식별한다. 만약 파드에 OwnerReference이 없거나
OwnerReference가 컨트롤러(Controller) 가 아니고 레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를
가지게 될 것이다.
레플리카셋을 사용하는 시기
레플리카셋은 지정된 수의 파드 레플리카가 항상 실행되도록 보장한다.
그러나 디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께
파드에 대한 선언적 업데이트를 제공하는 상위 개념이다.
따라서 우리는 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면
레플리카셋을 직접적으로 사용하기 보다는 디플로이먼트를 사용하는 것을 권장한다.
이는 레플리카셋 오브젝트를 직접 조작할 필요가 없다는 것을 의미한다.
대신 디플로이먼트를 이용하고 사양 부분에서 애플리케이션을 정의하면 된다.
단독(bare) 파드를 생성하는 것에는 문제가 없지만, 단독 파드가 레플리카셋의 셀렉터와 일치하는 레이블을 가지지
않도록 하는 것을 강력하게 권장한다. 그 이유는 레플리카셋이 소유하는 파드가 템플릿에 명시된 파드에만 국한되지 않고,
이전 섹션에서 명시된 방식에 의해서도 다른 파드의 획득이 가능하기 때문이다.
레플리카셋이 해당 파드를 소유한 것을 볼 수 있으며 새 파드 및 기존 파드의 수가
레플리카셋이 필요로 하는 수와 일치할 때까지 사양에 따라 신규 파드만 생성한다. 파드를 가져온다.
kubectl get pods
다음 출력에서 볼 수 있다.
NAME READY STATUS RESTARTS AGE
frontend-hmmj2 1/1 Running 0 9s
pod1 1/1 Running 0 36s
pod2 1/1 Running 0 36s
이러한 방식으로 레플리카셋은 템플릿을 사용하지 않는 파드를 소유하게 된다.
레플리카셋 매니페스트 작성하기
레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 apiVersion, kind, metadata 필드가 필요하다.
레플리카셋에 대한 kind 필드의 값은 항상 레플리카셋이다.
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 apps/v1은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 apps/v1beta2은 사용 중단(deprecated)되었다.
API 버전에 대해서는 frontend.yaml 예제의 첫 번째 줄을 참고한다.
.spec.template은 레이블을 붙이도록 되어있는 파드 템플릿이다.
우리는 frontend.yaml 예제에서 tier: frontend이라는 레이블을 하나 가지고 있다.
이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
템플릿의 재시작 정책 필드인
.spec.template.spec.restartPolicy는 기본값인 Always만 허용된다.
파드 셀렉터
.spec.selector 필드는 레이블 셀렉터이다.
앞서 논의한 것처럼 이 레이블은 소유될 가능성이 있는 파드를 식별하는데 사용된다.
우리 frontend.yaml 예제에서의 셀렉터는 다음과 같다.
matchLabels:tier:frontend
레플리카셋에서 .spec.template.metadata.labels는 spec.selector과 일치해야 하며
그렇지 않으면 API에 의해 거부된다.
참고: 2개의 레플리카셋이 동일한 .spec.selector필드를 지정한 반면, 다른 .spec.template.metadata.labels와 .spec.template.spec 필드를 명시한 경우, 각 레플리카셋은 다른 레플리카셋이 생성한 파드를 무시한다.
레플리카
.spec.replicas를 설정해서 동시에 동작하는 파드의 수를 지정할 수 있다.
레플리카셋은 파드의 수가 일치하도록 생성 및 삭제한다.
레플리카셋을 --cascade=orphan 옵션과 함께 kubectl delete를 사용하면 연관 파드에 영향을 주지 않고 삭제할 수 있다.
REST API 또는 client-go 라이브러리를 이용할 때는 propagationPolicy에 Orphan을 설정해야 한다.
예시:
원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다.
기존 .spec.selector와 신규 .spec.selector가 같으면 새 레플리카셋은 기존 파드를 선택한다.
하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다.
컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 디플로이먼트를 이용하면 된다.
이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다.
레플리카셋에서 파드 격리
레이블을 변경하면 레플리카셋에서 파드를 제거할 수 있다. 이 방식은 디버깅과 데이터 복구 등을
위해 서비스에서 파드를 제거하는 데 사용할 수 있다. 이 방식으로 제거된 파드는 자동으로 교체된다(
레플리카의 수가 변경되지 않는다고 가정한다).
레플리카셋의 스케일링
레플리카셋을 손쉽게 스케일 업 또는 다운하는 방법은 단순히 .spec.replicas 필드를 업데이트 하면 된다.
레플리카셋 컨트롤러는 일치하는 레이블 셀렉터가 있는 파드가 의도한 수 만큼 가용하고 운영 가능하도록 보장한다.
디플로이먼트는 레플리카셋을 소유하거나 업데이트를 하고,
파드의 선언적인 업데이트와 서버측 롤링 업데이트를 할 수 있는 오브젝트이다.
레플리카셋은 단독으로 사용할 수 있지만, 오늘날에는 주로 디플로이먼트로 파드의 생성과 삭제 그리고 업데이트를 오케스트레이션하는 메커니즘으로 사용한다.
디플로이먼트를 이용해서 배포할 때 생성되는 레플리카셋을 관리하는 것에 대해 걱정하지 않아도 된다.
디플로이먼트는 레플리카셋을 소유하거나 관리한다.
따라서 레플리카셋을 원한다면 디플로이먼트를 사용하는 것을 권장한다.
기본 파드
사용자가 직접 파드를 생성하는 경우와는 다르게, 레플리카셋은 노드 장애 또는 노드의 커널 업그레이드와 같은 관리 목적의 중단 등 어떤 이유로든 종료되거나 삭제된 파드를 교체한다. 이런 이유로 애플리케이션이 단일 파드가 필요하더라도 레플리카셋을 이용하는 것을 권장한다. 레플리카셋을 프로세스 관리자와 비교해서 생각해본다면, 레플리카셋은 단일 노드에서의 개별 프로세스들이 아닌 다수의 노드에 걸쳐있는 다수의 파드를 관리하는 것이다. 레플리카셋은 로컬 컨테이너의 재시작을 노드에 있는 어떤 에이전트에게 위임한다(예를들어 Kubelet 또는 도커).
잡
스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 잡을 이용한다
(즉, 배치 잡).
데몬셋
머신 모니터링 또는 머신 로깅과 같은 머신-레벨의 기능을 제공하는 파드를 위해서는 레플리카셋 대신
데몬셋을 사용한다.
이러한 파드의 수명은 머신의 수명과 연관되어 있고, 머신에서 다른 파드가 시작하기 전에 실행되어야 하며,
머신의 재부팅/종료가 준비되었을 때, 해당 파드를 종료하는 것이 안전하다.
레플리케이션 컨트롤러
레플리카셋은 레플리케이션 컨트롤러를 계승하였다.
이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 레이블 사용자 가이드에
설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
3.4.2.3 - 스테이트풀셋
스테이트풀셋은 애플리케이션의 스테이트풀을 관리하는데 사용하는 워크로드 API 오브젝트이다.
디플로이먼트와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다.
스토리지 볼륨을 사용해서 워크로드에 지속성을 제공하려는 경우, 솔루션의 일부로 스테이트풀셋을 사용할 수 있다. 스테이트풀셋의 개별 파드는 장애에 취약하지만, 퍼시스턴트 파드 식별자는 기존 볼륨을 실패한 볼륨을 대체하는 새 파드에 더 쉽게 일치시킬 수 있다.
스테이트풀셋 사용
스테이트풀셋은 다음 중 하나 또는 이상이 필요한 애플리케이션에
유용하다.
안정된, 고유한 네트워크 식별자.
안정된, 지속성을 갖는 스토리지.
순차적인, 정상 배포(graceful deployment)와 스케일링.
순차적인, 자동 롤링 업데이트.
위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다.
만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포,
삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카셋(ReplicaSet)을
제공하는 워크로드 오브젝트를 사용해서 애플리케이션을 배포해야 한다.
디플로이먼트 또는
레플리카셋과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다.
제한사항
파드에 지정된 스토리지는 관리자에 의해 퍼시스턴트 볼륨 프로비저너를 기반으로 하는 storage class 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 삭제되지 않는다. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 헤드리스 서비스가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
apiVersion:v1kind:Servicemetadata:name:nginxlabels:app:nginxspec:ports:- port:80name:webclusterIP:Noneselector:app:nginx---apiVersion:apps/v1kind:StatefulSetmetadata:name:webspec:selector:matchLabels:app:nginx# has to match .spec.template.metadata.labelsserviceName:"nginx"replicas:3# by default is 1template:metadata:labels:app:nginx# has to match .spec.selector.matchLabelsspec:terminationGracePeriodSeconds:10containers:- name:nginximage:k8s.gcr.io/nginx-slim:0.8ports:- containerPort:80name:webvolumeMounts:- name:wwwmountPath:/usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name:wwwspec:accessModes:["ReadWriteOnce"]storageClassName:"my-storage-class"resources:requests:storage:1Gi
위의 예시에서:
이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 퍼시스턴트 볼륨을 사용해서 안정적인 스토리지를 제공한다.
스테이트풀셋의 .spec.selector 필드는 .spec.template.metadata.labels 레이블과 일치하도록 설정해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 .spec.selector 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
파드 신원
스테이트풀셋 파드는 순서, 안정적인 네트워크 신원
그리고 안정적인 스토리지로 구성되는 고유한 신원을 가진다.
신원은 파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다.
순서 색인
N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있는
각 파드에 0에서 N-1 까지의 정수가 순서대로 할당되며 해당 스테이트풀셋 내에서 고유 하다.
안정적인 네트워크 신원
스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서
호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은
$(statefulset name)-$(ordinal) 이다. 위의 예시에서 생성된 3개 파드의 이름은
web-0,web-1,web-2 이다.
스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해
헤드리스 서비스를 사용할 수 있다.
이 서비스가 관리하는 도메인은 $(service name).$(namespace).svc.cluster.local 의 형식을 가지며,
여기서 "cluster.local"은 클러스터 도메인이다.
각 파드는 생성되면 $(podname).$(governing service domain) 형식을 가지고
일치되는 DNS 서브도메인을 가지며, 여기서 거버닝 서비스(governing service)는
스테이트풀셋의 serviceName 필드에 의해 정의된다.
클러스터에서 DNS가 구성된 방식에 따라, 새로 실행된 파드의 DNS 이름을
즉시 찾지 못할 수 있다. 이 동작은 클러스터의 다른 클라이언트가
파드가 생성되기 전에 파드의 호스트 이름에 대한 쿼리를 이미 보낸 경우에 발생할 수 있다.
네거티브 캐싱(DNS에서 일반적)은 이전에 실패한 조회 결과가
파드가 실행된 후에도 적어도 몇 초 동안 기억되고 재사용됨을 의미한다.
파드를 생성한 후 즉시 파드를 검색해야 하는 경우, 몇 가지 옵션이 있다.
DNS 조회에 의존하지 않고 쿠버네티스 API를 직접(예를 들어 watch 사용) 쿼리한다.
쿠버네티스 DNS 공급자의 캐싱 시간(일반적으로 CoreDNS의 컨피그맵을 편집하는 것을 의미하며, 현재 30초 동안 캐시함)을 줄인다.
제한사항 섹션에서 언급한 것처럼 사용자는
파드의 네트워크 신원을 책임지는
헤드리스 서비스를 생성할 책임이 있다.
여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고,
그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다.
클러스터 도메인
서비스 (ns/이름)
스테이트풀셋 (ns/이름)
스테이트풀셋 도메인
파드 DNS
파드 호스트 이름
cluster.local
default/nginx
default/web
nginx.default.svc.cluster.local
web-{0..N-1}.nginx.default.svc.cluster.local
web-{0..N-1}
cluster.local
foo/nginx
foo/web
nginx.foo.svc.cluster.local
web-{0..N-1}.nginx.foo.svc.cluster.local
web-{0..N-1}
kube.local
foo/nginx
foo/web
nginx.foo.svc.kube.local
web-{0..N-1}.nginx.foo.svc.kube.local
web-{0..N-1}
참고: 클러스터 도메인이 달리 구성된 경우가
아니라면 cluster.local로 설정된다.
안정된 스토리지
쿠버네티스는 각 VolumeClaimTemplate마다 하나의 퍼시스턴트 볼륨을
생성한다. 위의 nginx 예시에서 각 파드는 my-storage-class 라는 스토리지 클래스와
1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면
파드의 volumeMounts 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다.
이것은 반드시 수동으로 해야 한다.
파드 이름 레이블
스테이트풀셋 컨트롤러(Controller)
가 파드를 생성할 때 파드 이름으로 statefulset.kubernetes.io/pod-name
레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를
연결할 수 있다.
디플로이먼트와 스케일링 보증
N개의 레플리카가 있는 스테이트풀셋이 파드를 배포할 때 연속해서 {0..N-1}의 순서로 생성한다.
파드가 삭제될 때는 {N-1..0}의 순서인 역순으로 종료된다.
파드에 스케일링 작업을 적용하기 전에 모든 선행 파드가 Running 및 Ready 상태여야 한다.
파드가 종료되기 전에 모든 후속 파드가 완전히 종료 되어야 한다.
스테이트풀셋은 pod.Spec.TerminationGracePeriodSeconds 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 스테이트풀셋 파드 강제 삭제를 참고한다.
위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가
배포된다. web-1은 web-0이
Running 및 Ready 상태가 되기 전에는 배포되지 않으며,
web-2 도 web-1이 Running 및 Ready 상태가 되기 전에는 배포되지 않는다. 만약 web-1이 Running 및 Ready 상태가 된 이후,
web-2가 시작되기 전에 web-0이 실패하게 된다면, web-2는 web-0이 성공적으로 재시작이되고,
Running 및 Ready 상태가 되기 전까지 시작되지 않는다.
만약 사용자가 배포된 예제의 스테이트풀셋을 replicas=1 으로 패치해서
스케일한 경우 web-2가 먼저 종료된다. web-1은 web-2가 완전히 종료 및 삭제되기
전까지 정지되지 않는다. 만약 web-2의 종료 및 완전히 중지되고, web-1이 종료되기 전에
web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
되기 전까지 종료되지 않는다.
파드 관리 정책
쿠버네티스 1.7 및 이후에는 스테이트풀셋의 .spec.podManagementPolicy 필드를
통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.
OrderedReady 파드 관리
OrderedReady 파드 관리는 스테이트풀셋의 기본이다.
이것은 위에서 설명한 행위를 구현한다.
병렬 파드 관리
병렬 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를
병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나
종료에 앞서 파드가 Running 및 Ready 상태가 되거나 완전히 종료되기를 기다리지 않는다.
이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을
받지 않는다.
업데이트 전략
쿠버네티스 1.7 및 이후에는 스테이트풀셋의 .spec.updateStrategy 필드는 스테이트풀셋의
파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를
구성하거나 비활성화 할 수 있다.
삭제 시(On Delete)
OnDelete 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의
.spec.updateStrategy.type 은 OnDelete 를 설정하며, 스테이트풀셋 컨트롤러는
스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의
.spec.template를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
롤링 업데이트
롤링 업데이트 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
구현한다. 롤링 업데이트는 .spec.updateStrategy 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 롤링 업데이트 가 .spec.updateStrategy.type 에 설정되면
스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이
순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지),
각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될
때까지 기다린다.
파티션(Partition)
롤링 업데이트 의 업데이트 전략은 .spec.updateStrategy.rollingUpdate.partition
를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 .spec.template 가
업데이트 될 때 부여된 수가 파티션보다 크거나 같은 모든 파드가 업데이트 된다.
파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며,
삭제 된 경우라도 이전 버전에서 재생성된다.
만약 스테이트풀셋의 .spec.updateStrategy.rollingUpdate.partition 이
.spec.replicas 보다 큰 경우 .spec.template 의 업데이트는 해당 파드에 전달하지 않는다.
대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.
강제 롤백
기본 파드 관리 정책 (OrderedReady)과
함께 롤링 업데이트를 사용할 경우
직접 수동으로 복구를 해야하는 고장난 상태가 될 수 있다.
만약 파드 템플릿을 Running 및 Ready 상태가 되지 않는 구성으로 업데이트하는
경우(예시: 잘못된 바이너리 또는 애플리케이션-레벨 구성 오류로 인한)
스테이트풀셋은 롤아웃을 중지하고 기다린다.
이 상태에서는 파드 템플릿을 올바른 구성으로 되돌리는 것으로 충분하지 않다.
알려진 이슈로
인해 스테이트풀셋은 손상된 파드가 준비(절대 되지 않음)될 때까지 기다리며
작동하는 구성으로 되돌아가는 시도를 하기
전까지 기다린다.
템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로
실행하려고 시도한 모든 파드를 삭제해야 한다.
그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다.
apiVersion:apps/v1kind:DaemonSetmetadata:name:fluentd-elasticsearchnamespace:kube-systemlabels:k8s-app:fluentd-loggingspec:selector:matchLabels:name:fluentd-elasticsearchtemplate:metadata:labels:name:fluentd-elasticsearchspec:tolerations:# this toleration is to have the daemonset runnable on master nodes# remove it if your masters can't run pods- key:node-role.kubernetes.io/mastereffect:NoSchedulecontainers:- name:fluentd-elasticsearchimage:quay.io/fluentd_elasticsearch/fluentd:v2.5.2resources:limits:memory:200Mirequests:cpu:100mmemory:200MivolumeMounts:- name:varlogmountPath:/var/log- name:varlibdockercontainersmountPath:/var/lib/docker/containersreadOnly:trueterminationGracePeriodSeconds:30volumes:- name:varloghostPath:path:/var/log- name:varlibdockercontainershostPath:path:/var/lib/docker/containers
.spec.template 는 파드 템플릿이다. 이것은 중첩되어 있다는 점과 apiVersion 또는 kind 를 가지지 않는 것을 제외하면 파드와 정확히 같은 스키마를 가진다.
데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
한다(파드 셀렉터를 본다).
데몬셋의 파드 템플릿의 RestartPolicy는 Always 를 가져야 하며,
명시되지 않은 경우 기본으로 Always가 된다.
파드 셀렉터
.spec.selector 필드는 파드 셀렉터이다. 이것은
잡의 .spec.selector 와 같은 동작을 한다.
쿠버네티스 1.8 부터는 레이블이 .spec.template 와 일치하는 파드 셀렉터를 명시해야 한다.
파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.
셀렉터의 기본 값은 kubectl apply 과 호환되지 않는다.
또한, 한 번 데몬셋이 만들어지면 .spec.selector 의 변형은 가능하지 않다.
파드 셀렉터를 변형하면 의도하지 않게 파드는 고아가 되거나 사용자에게 혼란을 주는 것으로 밝혀졌다.
.spec.selector 는 다음 2개의 필드로 구성된 오브젝트이다.
matchLabels - 레플리케이션 컨트롤러의 .spec.selector 와 동일하게 작동한다.
matchExpressions - 키, 값 목록 그리고 키 및 값에 관련된 연산자를
명시해서 보다 정교한 셀렉터를 만들 수 있다.
2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다.
만약 .spec.selector 를 명시하면, 이것은 .spec.template.metadata.labels 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다.
오직 일부 노드에서만 파드 실행
만약 .spec.template.spec.nodeSelector 를 명시하면 데몬셋 컨트롤러는
노드 셀렉터와
일치하는 노드에 파드를 생성한다. 마찬가지로 .spec.template.spec.affinity 를 명시하면
데몬셋 컨트롤러는 노드 어피니티와 일치하는 노드에 파드를 생성한다.
만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.
데몬 파드가 스케줄 되는 방법
기본 스케줄러로 스케줄
FEATURE STATE:Kubernetes v1.20 [stable]
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다.
이에 대한 이슈를 소개한다.
파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 Pending 상태로 생성된다.
그러나 데몬셋 파드는 Pending 상태로 생성되지 않는다.
이것은 사용자에게 혼란을 준다.
파드 선점은
기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
ScheduleDaemonSetPods 로 데몬셋 파드에 .spec.nodeName 용어 대신
NodeAffinity 용어를 추가해서 데몬셋 컨트롤러 대신 기본
스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본
스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에
이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며,
데몬셋의 spec.template 은 변경되지 않는다.
또한, 데몬셋 파드에 node.kubernetes.io/unschedulable:NoSchedule 이 톨러레이션(toleration)으로
자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를
스케줄링시 unschedulable 노드를 무시한다.
테인트(taints)와 톨러레이션(tolerations)
데몬 파드는
테인트와 톨러레이션을 존중하지만,
다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에
톨러레이션을 추가한다.
톨러레이션 키
영향
버전
설명
node.kubernetes.io/not-ready
NoExecute
1.13+
네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다.
node.kubernetes.io/unreachable
NoExecute
1.13+
네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다.
node.kubernetes.io/disk-pressure
NoSchedule
1.8+
데몬셋 파드는 기본 스케줄러에서 디스크-압박(disk-pressure) 속성을 허용한다.
node.kubernetes.io/memory-pressure
NoSchedule
1.8+
데몬셋 파드는 기본 스케줄러에서 메모리-압박(memory-pressure) 속성을 허용한다.
node.kubernetes.io/unschedulable
NoSchedule
1.12+
데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다.
node.kubernetes.io/network-unavailable
NoSchedule
1.12+
호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다.
데몬 파드와 통신
데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다.
푸시(Push): 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
구성되어있다. 그들은 클라이언트들을 가지지 않는다.
노드IP와 알려진 포트: 데몬셋의 파드는 호스트 포트를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
DNS: 동일한 파드 셀렉터로 헤드리스 서비스를 만들고,
그 다음에 엔드포인트 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를
검색한다.
서비스: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
임의의 노드의 데몬에 도달한다(특정 노드에 도달할 방법이 없다).
데몬셋 업데이트
만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로
일치하지 않는 노드에서 파드를 삭제한다.
사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든
필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는
다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다.
사용자는 데몬셋을 삭제할 수 있다. 만약 kubectl 에서 --cascade=false 를 명시하면
파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면,
새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은
updateStrategy 에 따라 파드를 교체한다.
데몬 프로세스를 직접 노드에서 시작해서 실행하는 것도 당연히 가능하다.
(예: init, upstartd 또는 systemd 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬
프로세스를 실행하면 몇 가지 이점 있다.
애플리케이션과 동일한 방법으로 데몬을 모니터링하고 로그 관리를 할 수 있다.
데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, kubectl).
리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서
데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다
(예: 도커에서 직접적으로 시작).
베어(Bare) 파드
직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나
데몬셋은 노드 장애 또는 커널 업그레이드와 같이 변경사항이 많은 노드 유지보수의 경우를 비롯하여
어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를
생성하는 것보다는 데몬 셋을 사용해야 한다.
스태틱(static) 파드
Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
스태틱 파드라고 부른다.
데몬셋과는 다르게 스태틱 파드는 kubectl
또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지
않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단될 수 있다.
디플로이먼트
데몬셋은 파드를 생성한다는 점에서 디플로이먼트와 유사하고,
해당 파드에서는 프로세스가 종료되지 않을 것으로
예상한다(예: 웹 서버).
파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
3.4.2.5 - 잡
잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다.
파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의
성공 완료에 도달하면, 작업(즉, 잡)이 완료된다. 잡을 삭제하면 잡이 생성한
파드가 정리된다.
간단한 사례는 잡 오브젝트를 하나 생성해서 파드 하나를 안정적으로 실행하고 완료하는 것이다.
첫 번째 파드가 실패 또는 삭제된 경우(예로는 노드 하드웨어의 실패 또는
노드 재부팅) 잡 오브젝트는 새로운 파드를 기동시킨다.
잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.
예시 잡 실행하기
다음은 잡 설정 예시이다. 예시는 파이(π)의 2000 자리까지 계산해서 출력한다.
이를 완료하는 데 약 10초가 소요된다.
만약 잡 컨트롤러가 어떤 이유(ResourceQuota 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우,
요청한 것보다 적은 수의 파드가 있을 수 있다.
잡 컨트롤러는 동일한 잡에서 과도하게 실패한 이전 파드들로 인해 새로운 파드의 생성을 조절할 수 있다.
파드가 정상적으로(gracefully) 종료되면, 중지하는데 시간이 소요된다.
파드와 컨테이너 장애 처리하기
파드내 컨테이너의 프로세스가 0이 아닌 종료 코드로 종료되었거나 컨테이너 메모리 제한을
초과해서 죽는 등의 여러가지 이유로 실패할 수 있다. 만약 이런 일이
발생하고 .spec.template.spec.restartPolicy = "OnFailure" 라면 파드는
노드에 그대로 유지되지만, 컨테이너는 다시 실행된다. 따라서 프로그램은 로컬에서 재시작될 때의
케이스를 다루거나 .spec.template.spec.restartPolicy = "Never" 로 지정해야 한다.
더 자세한 정보는 파드 라이프사이클의 restartPolicy 를 본다.
파드가 노드에서 내보내지는 경우(노드 업그레이드, 재부팅, 삭제 등) 또는 파드의 컨테이너가 실패
되고 .spec.template.spec.restartPolicy = "Never" 로 설정됨과 같은 여러 이유로
전체 파드가 실패할 수 있다. 파드가 실패하면 잡 컨트롤러는
새 파드를 시작한다. 이 의미는 애플리케이션이 새 파드에서 재시작될 때 이 케이스를 처리해야
한다는 점이다. 특히, 이전 실행으로 인한 임시파일, 잠금, 불완전한 출력 그리고 이와 유사한
것들을 처리해야 한다.
.spec.parallelism = 1, .spec.completions = 1 그리고
.spec.template.spec.restartPolicy = "Never" 를 지정하더라도 같은 프로그램을
두 번 시작하는 경우가 있다는 점을 참고한다.
.spec.parallelism 그리고 .spec.completions 를 모두 1보다 크게 지정한다면 한번에
여러 개의 파드가 실행될 수 있다. 따라서 파드는 동시성에 대해서도 관대(tolerant)해야 한다.
파드 백오프(backoff) 실패 정책
구성 등의 논리적 오류로 인해 약간의 재시도 이후에
잡을 실패하게 만들려는 경우가 있다.
이렇게 하려면 .spec.backoffLimit 에 잡을 실패로 간주하기 이전에
재시도할 횟수를 설정한다. 백오프 제한은 기본적으로 6으로 설정되어 있다. 잡과
관련한 실패한 파드는 최대 6분안에서 기하급수적으로 증가하는 백-오프 지연 (10초, 20초, 40초 ...)
한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나
해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프
카운트가 재설정된다.
참고: 만약 잡에 restartPolicy = "OnFailure" 가 있는 경우 잡 백오프 한계에
도달하면 잡을 실행 중인 컨테이너가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
더 어려워질 수 있다. 디버깅하거나 로깅 시스템을 사용해서 실패한 작업의 결과를 실수로 손실되지 않도록
하려면 restartPolicy = "Never" 로 설정하는 것을 권장한다.
잡의 종료와 정리
잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다. 이를 유지하면
완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.
잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.
kubectl 로 잡을 삭제할 수 있다 (예: kubectl delete jobs/pi 또는 kubectl delete -f ./job.yaml). kubectl 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.
기본적으로 파드의 실패(restartPolicy=Never) 또는 컨테이너가 오류(restartPolicy=OnFailure)로 종료되지 않는 한, 잡은 중단되지 않고 실행되고
이때 위에서 설명했던 .spec.backoffLimit 까지 연기된다. .spec.backoffLimit 에 도달하면 잡은 실패로 표기되고 실행 중인 모든 파드는 종료된다.
잡을 종료하는 또 다른 방법은 유효 데드라인을 설정하는 것이다.
잡의 .spec.activeDeadlineSeconds 필드를 초 단위로 설정하면 된다.
activeDeadlineSeconds 는 생성된 파드의 수에 관계 없이 잡의 기간에 적용된다.
잡이 activeDeadlineSeconds 에 도달하면, 실행 중인 모든 파드가 종료되고 잡의 상태는 reason: DeadlineExceeded 와 함께 type: Failed 가 된다.
잡의 .spec.activeDeadlineSeconds 는 .spec.backoffLimit 보다 우선한다는 점을 참고한다. 따라서 하나 이상 실패한 파드를 재시도하는 잡은 backoffLimit 에 도달하지 않은 경우에도 activeDeadlineSeconds 에 지정된 시간 제한에 도달하면 추가 파드를 배포하지 않는다.
잡의 사양과 잡의 파드 템플릿 사양에는 모두 activeDeadlineSeconds 필드가 있다는 점을 참고한다. 이 필드를 적절한 레벨로 설정해야 한다.
restartPolicy 는 잡 자체에 적용되는 것이 아니라 파드에 적용된다는 점을 유념한다. 잡의 상태가 type: Failed 이 되면, 잡의 자동 재시작은 없다.
즉, .spec.activeDeadlineSeconds 와 .spec.backoffLimit 로 활성화된 잡의 종료 메커니즘은 영구적인 잡의 실패를 유발하며 이를 해결하기 위해 수동 개입이 필요하다.
완료된 잡을 자동으로 정리
완료된 잡은 일반적으로 시스템에서 더 이상 필요로 하지 않는다. 시스템 내에
이를 유지한다면 API 서버에 부담이 된다.
만약 크론잡과
같은 상위 레벨 컨트롤러가 잡을 직접 관리하는 경우,
지정된 용량 기반 정리 정책에 따라 크론잡이 잡을 정리할 수 있다.
완료된 잡을 위한 TTL 메커니즘
FEATURE STATE:Kubernetes v1.12 [alpha]
완료된 잡 (Complete 또는 Failed)을 자동으로 정리하는 또 다른 방법은
잡의 .spec.ttlSecondsAfterFinished 필드를 지정해서 완료된 리소스에 대해
TTL 컨트롤러에서
제공하는 TTL 메커니즘을 사용하는
것이다.
TTL 컨트롤러는 잡을 정리하면 잡을 계단식으로 삭제한다.
즉, 잡과 함께 파드와 같은 종속 오브젝트를 삭제한다. 잡을
삭제하면 finalizer와 같은 라이프사이클 보증이 보장되는 것을
참고한다.
만약 필드를 0 으로 설정하면, 잡이 완료된 직후에 자동으로
삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된
후에 TTL 컨트롤러에 의해 정리되지 않는다.
이 TTL 메커니즘은 기능 게이트 TTLAfterFinished와 함께 알파 단계이다. 더
자세한 정보는 완료된 리소스를 위한
TTL 컨트롤러
문서를 본다.
잡 패턴
잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다. 잡 오브젝트는 과학
컴퓨팅(scientific computing)에서 일반적으로 사용되는 밀접하게 통신하는 병렬 프로세스를 지원하도록
설계되지 않았다. 잡 오브젝트는 독립적이지만 관련된 작업 항목 집합의 병렬 처리를 지원한다.
여기에는 전송할 이메일들, 렌더링할 프레임, 코드 변환이 필요한 파일, NoSQL 데이터베이스에서의
키 범위 스캔 등이 있다.
복잡한 시스템에는 여러 개의 다른 작업 항목 집합이 있을 수 있다. 여기서는 사용자와
함께 관리하려는 하나의 작업 항목 집합 — 배치 잡 을 고려하고 있다.
병렬 계산에는 몇몇 다른 패턴이 있으며 각각의 장단점이 있다.
트레이드오프는 다음과 같다.
각 작업 항목에 대한 하나의 잡 오브젝트 vs 모든 작업 항목에 대한 단일 잡 오브젝트. 후자는
작업 항목 수가 많은 경우 더 적합하다. 전자는 사용자와 시스템이 많은 수의 잡 오브젝트를
관리해야 하는 약간의 오버헤드를 만든다.
작업 항목과 동일한 개수의 파드 생성 vs 각 파드에서 다수의 작업 항목을 처리.
전자는 일반적으로 기존 코드와 컨테이너를 거의 수정할 필요가 없다. 후자는
이전 글 머리표(-)와 비슷한 이유로 많은 수의 작업 항목에 적합하다.
여러 접근 방식이 작업 큐를 사용한다. 이를 위해서는 큐 서비스를 실행하고,
작업 큐를 사용하도록 기존 프로그램이나 컨테이너를 수정해야 한다.
다른 접근 방식들은 기존에 컨테이너화된 애플리케이션에 보다 쉽게 적용할 수 있다.
여기에 트레이드오프가 요약되어있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
패턴 이름은 예시와 더 자세한 설명을 위한 링크이다.
.spec.completions 로 완료를 지정할 때, 잡 컨트롤러에 의해 생성된 각 파드는
동일한 사양을 갖는다. 이 의미는
작업의 모든 파드는 동일한 명령 줄과 동일한 이미지,
동일한 볼륨, (거의) 동일한 환경 변수를 가진다는 점이다. 이 패턴은
파드가 다른 작업을 수행하도록 배열하는 다른 방법이다.
이 표는 각 패턴에 필요한 .spec.parallelism 그리고 .spec.completions 설정을 보여준다.
여기서 W 는 작업 항목의 수이다.
일반적으로 잡 오브젝트를 생성할 때 .spec.selector 를 지정하지 않는다.
시스템의 기본적인 로직은 잡이 생성될 때 이 필드를 추가한다.
이것은 다른 잡과 겹치지 않는 셀렉터 값을 선택한다.
그러나, 일부 케이스에서는 이 자동화된 설정 셀렉터를 재정의해야 할 수도 있다.
이를 위해 잡의 .spec.selector 를 설정할 수 있다.
이 것을 할 때는 매우 주의해야 한다. 만약 해당 잡의 파드에 고유하지
않고 연관이 없는 파드와 일치하는 레이블 셀렉터를 지정하면, 연관이 없는 잡의 파드가 삭제되거나,
해당 잡이 다른 파드가 완료한 것으로 수를 세거나, 하나 또는
양쪽 잡 모두 파드 생성이나 실행 완료를 거부할 수도 있다. 만약 고유하지 않은 셀렉터가
선택된 경우, 다른 컨트롤러(예: 레플리케이션 컨트롤러)와 해당 파드는
예측할 수 없는 방식으로 작동할 수 있다. 쿠버네티스는 당신이 .spec.selector 를 지정할 때
발생하는 실수를 막을 수 없을 것이다.
다음은 이 기능을 사용하려는 경우의 예시이다.
잡 old 가 이미 실행 중이다. 기존 파드가 계속
실행되기를 원하지만, 잡이 생성한 나머지 파드에는 다른
파드 템플릿을 사용하고 잡으로 하여금 새 이름을 부여하기를 원한다.
그러나 관련된 필드들은 업데이트가 불가능하기 때문에 잡을 업데이트할 수 없다.
따라서 kubectl delete jobs/old --cascade=false 를 사용해서
잡 old 를 삭제하지만, 파드를 실행 상태로 둔다.
삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다.
새 잡 자체는 a8f3d00d-c6d2-11e5-9f87-42010af00002 와 다른 uid 를 가지게 될 것이다.
manualSelector: true 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런
불일치를 허용한다.
대안
베어(Bare) 파드
파드가 실행 중인 노드가 재부팅되거나 실패하면 파드가 종료되고
다시 시작되지 않는다. 그러나 잡은 종료된 항목을 대체하기 위해 새 파드를 생성한다.
따라서, 애플리케이션에 단일 파드만 필요한 경우에도 베어 파드 대신
잡을 사용하는 것을 권장한다.
레플리케이션 컨트롤러
잡은 레플리케이션 컨트롤러를 보완한다.
레플리케이션 컨트롤러는 종료하지 않을 파드(예: 웹 서버)를 관리하고, 잡은 종료될 것으로
예상되는 파드(예: 배치 작업)를 관리한다.
파드 라이프사이클에서 설명한 것처럼, 잡 은 오직OnFailure 또는 Never 와 같은 RestartPolicy 를 사용하는 파드에만 적절하다.
(참고: RestartPolicy 가 설정되지 않은 경우에는 기본값은 Always 이다.)
단일 잡으로 컨트롤러 파드 시작
또 다른 패턴은 단일 잡이 파드를 생성한 후 다른 파드들을 생성해서 해당 파드들에
일종의 사용자 정의 컨트롤러 역할을 하는 것이다. 이를 통해 최대한의 유연성을 얻을 수 있지만,
시작하기에는 다소 복잡할 수 있으며 쿠버네티스와의 통합성이 낮아진다.
이 패턴의 한 예시는 파드를 시작하는 잡이다. 파드는 스크립트를 실행해서
스파크(Spark) 마스터 컨트롤러 (스파크 예시를 본다)를 시작하고,
스파크 드라이버를 실행한 다음, 정리한다.
이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,
파드 생성과 작업 할당 방법을 완전히 제어하고 유지한다는 것이다.
크론잡
CronJob을 사용해서 Unix 도구인 cron과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다.
3.4.2.6 - 가비지(Garbage) 수집
쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
소유자(owner)와 종속(dependent)
일부 쿠버네티스 오브젝트는 다른 오브젝트의 소유자이다. 예를 들어 레플리카셋은
파드 집합의 소유자이다. 소유자 오브젝트에게 소유된 오브젝트를 종속
이라고 한다. 모든 종속 오브젝트는 소유하는 오브젝트를 가르키는 metadata.ownerReferences
필드를 가지고 있다.
때때로, 쿠버네티스는 ownerReference 값을 자동적으로 설정한다.
예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의
ownerReference 필드를 자동으로 설정한다. 1.8 에서는 쿠버네티스가
레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋, 디플로이먼트, 잡
그리고 크론잡에 의해서 생성되거나 차용된 오브젝트의 ownerReference 값을
자동으로 설정한다.
또한 ownerReference 필드를 수동으로 설정해서 소유자와 종속 항목 간의
관계를 지정할 수도 있다.
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다.
네임스페이스 종속 항목은 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다.
네임스페이스 소유자는 반드시 종속 항목과 동일한 네임스페이스에 있어야 한다.
그렇지 않은 경우, 소유자 참조는 없는 것으로 처리되며, 소유자가 없는 것으로 확인되면
종속 항목이 삭제될 수 있다.
클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있다.
v1.20 이상에서 클러스터 범위의 종속 항목이 네임스페이스 종류를 소유자로 지정하면,
확인할 수 없는 소유자 참조가 있는 것으로 처리되고 가비지 수집이 될 수 없다.
v1.20 이상에서 가비지 수집기가 잘못된 교차 네임스페이스 ownerReference
또는 네임스페이스 종류를 참조하는 ownerReference 가 있는 클러스터 범위의 종속 항목을 감지하면,
OwnerRefInvalidNamespace 의 원인이 있는 경고 이벤트와 유효하지 않은 종속 항목의 involvedObject 가 보고된다.
kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace 를 실행하여
이러한 종류의 이벤트를 확인할 수 있다.
가비지 수집기의 종속 항목 삭제 방식 제어
오브젝트를 삭제할 때, 오브젝트의 종속 항목을 자동으로 삭제하는지의
여부를 지정할 수 있다. 종속 항목을 자동으로 삭제하는 것을 캐스케이딩(cascading)
삭제 라고 한다. 캐스케이딩 삭제 에는 백그라운드 와 포어그라운드 2가지 모드가 있다.
만약 종속 항목을 자동으로 삭제하지 않고 오브젝트를 삭제한다면,
종속 항목은 분리됨(orphaned) 이라고 한다.
포어그라운드 캐스케이딩 삭제
포어그라운드 캐스케이딩 삭제 에서는 루트 오브젝트가 먼저
"삭제 중(deletion in progress)" 상태가 된다. "삭제 중" 상태에서는
다음 사항이 적용된다.
오브젝트는 REST API를 통해 여전히 볼 수 있음
오브젝트에 deletionTimestamp 가 설정됨
오브젝트의 "foregroundDeletion"에 metadata.finalizers 값이 포함됨.
"삭제 중" 상태가 설정되면, 가비지
수집기는 오브젝트의 종속 항목을 삭제한다. 가비지 수집기는 모든
"차단" 종속 항목(ownerReference.blockOwnerDeletion=true 가 있는 오브젝트)의 삭제가 완료되면,
소유자 오브젝트를 삭제한다.
"foregroundDeletion" 에서는 ownerReference.blockOwnerDeletion=true 로
설정된 종속 항목만 소유자 오브젝트의 삭제를 차단한다는 것을 참고한다.
쿠버네티스 버전 1.7에서는 소유자 오브젝트에 대한 삭제 권한에 따라 blockOwnerDeletion 를 true로 설정하기 위해 사용자 접근을 제어하는
어드미션 컨트롤러가
추가되었기에 권한이 없는 종속 항목은 소유자 오브젝트의 삭제를 지연시킬 수 없다.
만약 오브젝트의 ownerReferences 필드가 컨트롤러(디플로이먼트 또는 레플리카셋과 같은)에
의해 설정된 경우 blockOwnerDeletion이 자동으로 설정되므로 이 필드를 수동으로 수정할 필요가 없다.
백그라운드 캐스케이딩 삭제
백그라운드 캐스케이딩 삭제 에서 쿠버네티스는 소유자 오브젝트를
즉시 삭제하고, 가비지 수집기는 백그라운드에서 종속 항목을
삭제한다.
캐스케이딩 삭제 정책 설정하기
캐스케이딩 삭제 정책을 제어하려면, 오브젝트를 삭제할 때 deleteOptions
인수를 propagationPolicy 필드에 설정한다. 여기에 가능한 값으로는 "Orphan",
"Foreground" 또는 "Background" 이다.
1.7 이전에서는 디플로이먼트와 캐스케이딩 삭제를 사용하면 반드시 propagationPolicy: Foreground
를 사용해서 생성된 레플리카셋뿐만 아니라 해당 파드도 삭제해야 한다. 만약 이 propagationPolicy
유형을 사용하지 않는다면, 레플리카셋만 삭제되고 파드는 분리된 상태로 남을 것이다.
더 많은 정보는 kubeadm/#149를 본다.
TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
잡(Job)만
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
처리하도록 확장될 수 있다.
알파(Alpha) 고지 사항: 이 기능은 현재 알파이고,
kube-apiserver와 kube-controller-manager와 함께
기능 게이트로 TTLAfterFinished 를 활성화할 수 있다.
TTL 컨트롤러
현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는
예시
와 같이 .spec.ttlSecondsAfterFinished 필드를 명시하여
완료된 잡(완료 또는 실패)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다.
리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),
TTL 컨트롤러는 해당 리소스가 정리될 수 있다고 가정한다.
TTL 컨트롤러가 리소스를 정리할때 리소스를 연속적으로 삭제한다. 이는
의존하는 오브젝트도 해당 리소스와 함께 삭제되는 것을 의미한다. 리소스가 삭제되면 완료자(finalizers)와
같은 라이프 사이클 보증이 적용 된다.
TTL 초(sec)는 언제든지 설정이 가능하다. 여기에 잡 필드 중
.spec.ttlSecondsAfterFinished 를 설정하는 몇 가지 예시가 있다.
작업이 완료된 다음, 일정 시간 후에 자동으로 잡이 정리될 수 있도록
리소스 메니페스트에 이 필드를 지정한다.
이미 완료된 기존 리소스에 이 새 기능을 적용하기 위해서 이 필드를
설정한다.
어드미션 웹후크 변형
을 사용해서
리소스 생성시 이 필드를 동적으로 설정 한다. 클러스터 관리자는 이것을
사용해서 완료된 리소스에 대해 TTL 정책을 적용할 수 있다.
리소스가 완료된 이후에
어드미션 웹후크 변형
을 사용해서 이 필드를 동적으로 설정하고, 리소스의 상태,
레이블 등에 따라 다른 TTL 값을 선택한다.
경고
TTL 초(sec) 업데이트
TTL 기간은, 예를 들어 잡의 .spec.ttlSecondsAfterFinished 필드는
리소스를 생성하거나 완료한 후에 수정할 수 있다. 그러나, 잡을
삭제할 수 있게 되면(TTL이 만료된 경우) 시스템은 TTL을 연장하기
위한 업데이트가 성공적인 API 응답을 리턴하더라도
작업이 유지되도록 보장하지 않는다.
시간 차이(Skew)
TTL 컨트롤러는 쿠버네티스 리소스에
저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의
시간 차이에 민감하며, 시간 차이에 의해서 TTL 컨트롤러가 잘못된 시간에 리소스
오브젝트를 정리하게 될 수 있다.
쿠버네티스에서는 시간 차이를 피하기 위해 모든 노드
(#6159를 본다)
에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는
아주 작아야 한다. 0이 아닌 TTL을 설정할때는 이 위험에 대해 유의해야 한다.
컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를 실행하는 경우,
kube-controller-manager 컨테이너에 설정된 시간대는
크론잡 컨트롤러가 사용하는 시간대로 결정한다.
크론잡 리소스에 대한 매니페스트를 생성할 때에는 제공하는 이름이
유효한 DNS 서브도메인 이름이어야 한다.
이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
11자를 자동으로 추가하고, 작업 이름의 최대 길이는
63자라는 제약 조건이 있기 때문이다.
크론잡
크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인
작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을
스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다.
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
0 0 13 * 5
크론잡 스케줄 표현을 생성하기 위해서 crontab.guru와 같은 웹 도구를 사용할 수도 있다.
크론잡의 한계
크론잡은 일정의 실행시간 마다 약 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는
특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지
않도록 해야겠지만, 완벽히 그럴 수는 없다. 따라서 잡은 멱등원 이 된다.
만약 startingDeadlineSeconds 가 큰 값으로 설정되거나, 설정되지 않고(디폴트 값),
concurrencyPolicy 가 Allow 로 설정될 경우, 잡은 항상 적어도 한 번은
실행될 것이다.
주의:startingDeadlineSeconds 가 10초 미만의 값으로 설정되면, 크론잡이 스케줄되지 않을 수 있다. 이는 크론잡 컨트롤러가 10초마다 항목을 확인하기 때문이다.
모든 크론잡에 대해 크론잡 컨트롤러 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.
Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
중요한 것은 만약 startingDeadlineSeconds 필드가 설정이 되면(nil 이 아닌 값으로), 컨트롤러는 마지막 일정부터 지금까지 대신 startingDeadlineSeconds 값에서 몇 개의 잡이 누락되었는지 카운팅한다. 예를 들면, startingDeadlineSeconds 가 200 이면, 컨트롤러는 최근 200초 내 몇 개의 잡이 누락되었는지 카운팅한다.
크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, concurrencyPolicy 가 Forbid 로 설정되었고, 크론잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다.
즉, 크론잡이 08:30:00 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고,
startingDeadlineSeconds 값이 설정되어 있지 않는다고 가정해보자. 만약 크론잡 컨트롤러가
08:29:00 부터 10:21:00 까지 고장이 나면, 일정을 놓친 작업 수가 100개를 초과하여 잡이 실행되지 않을 것이다.
이 개념을 더 자세히 설명하자면, 크론잡이 08:30:00 부터 매 분 실행되는 일정으로 설정되고,
startingDeadlineSeconds 이 200이라고 가정한다. 크론잡 컨트롤러가
전의 예시와 같이 고장났다고 하면 (08:29:00 부터 10:21:00 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함)
크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고,
잡은 그 잡이 대표하는 파드 관리에 책임이 있다.
새 컨트롤러
쿠버네티스 1.20부터 알파 기능으로 사용할 수 있는 크론잡 컨트롤러의 대체 구현이 있다. 크론잡 컨트롤러의 버전 2를 선택하려면, 다음의 기능 게이트 플래그를 kube-controller-manager에 전달한다.
레플리케이션컨트롤러 는 언제든지 지정된 수의 파드 레플리카가
실행 중임을 보장한다.
다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다.
레플리케이션 컨트롤러의 동작방식
파드가 너무 많으면 레플리케이션 컨트롤러가 추가적인 파드를 제거한다.
너무 적으면 레플리케이션 컨트롤러는 더 많은 파드를 시작한다.
수동으로 생성된 파드와 달리 레플리케이션 컨트롤러가 유지 관리하는 파드는 실패하거나 삭제되거나 종료되는 경우 자동으로 교체된다.
예를 들어, 커널 업그레이드와 같이 파괴적인 유지 보수 작업을 하고 난 이후의 노드에서 파드가 다시 생성된다.
따라서 애플리케이션에 하나의 파드만 필요한 경우에도 레플리케이션 컨트롤러를 사용해야 한다.
레플리케이션 컨트롤러는 프로세스 감시자(supervisor)와 유사하지만
단일 노드에서 개별 프로세스를 감시하는 대신 레플리케이션 컨트롤러는
여러 노드에서 여러 파드를 감시한다.
레플리케이션 컨트롤러는 디스커션에서 종종 "rc"로 축약되며
kubectl 명령에서 숏컷으로 사용된다.
간단한 경우는 하나의 레플리케이션 컨트롤러 오브젝트를 생성하여
한 개의 파드 인스턴스를 영구히 안정적으로 실행하는 것이다.
보다 복잡한 사용 사례는 웹 서버와 같이 복제된 서비스의 동일한 레플리카를 여러 개 실행하는 것이다.
레플리케이션 컨트롤러에 속한 모든 파드를 머신이 읽을 수 있는 형식으로 나열하기 위해 다음과 같은 명령을 사용할 수 있다.
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})echo$pods
출력 결과는 다음과 같다.
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
여기서 셀렉터는 레플리케이션컨트롤러(kubectl describe 의 출력에서 보인)의 셀렉터와 같고,
다른 형식의 파일인 replication.yaml 의 것과 동일하다. --output=jsonpath 는
반환된 목록의 각 파드 이름을 출력하도록 하는 옵션이다.
레플리케이션 컨트롤러의 Spec 작성
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 apiVersion, kind, metadata 와 같은 필드가 필요하다.
레플리케이션 컨트롤러 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
환경 설정 파일의 동작에 관련된 일반적인 정보는 쿠버네티스 오브젝트 관리를 참고한다.
로컬 컨테이너의 재시작의 경우, 레플리케이션 컨트롤러는 노드의 에이전트에게 위임한다.
예를 들어 Kubelet 혹은 도커이다.
레플리케이션 컨트롤러에서 레이블
레플리케이션 컨트롤러 자체는 레이블 (.metadata.labels) 을 가질 수 있다. 일반적으로 이것을 .spec.template.metadata.labels 와 동일하게 설정할 것이다. .metadata.labels 가 지정되어 있지 않은 경우,
기본은 .spec.template.metadata.labels 이다. 하지만 레이블은
다른 것이 허용되며, .metadata.labels 라벨은 레플리케이션 컨트롤러의
동작에 영향을 미치지 않는다.
파드 셀렉터
.spec.selector 필드는 레이블 셀렉터이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
직접 생성하거나 삭제된 파드와 다른 사람이나 프로세스가 생성하거나
삭제한 파드를 구분하지 않는다. 이렇게 하면 실행중인 파드에 영향을 주지 않고
레플리케이션 컨트롤러를 교체할 수 있다.
지정된 경우 .spec.template.metadata.labels 은
.spec.selector 와 동일해야 하며 그렇지 않으면 API에 의해 거부된다. .spec.selector 가 지정되지 않은 경우 기본값은
.spec.template.metadata.labels 이다.
또한 일반적으로 이 셀렉터와 레이블이 일치하는 파드를 직접
다른 레플리케이션 컨트롤러 또는 잡과 같은 다른 컨트롤러로 작성해서는 안된다.
그렇게 하면 레플리케이션 컨트롤러는 다른 파드를 생성했다고 생각한다.
쿠버네티스는 이런 작업을 중단해 주지 않는다.
중첩된 셀렉터들을 갖는 다수의 컨트롤러들을 종료하게 되면, 삭제된 것들은 스스로 관리를 해야 한다
(아래를 참조).
다수의 레플리카
.spec.replicas 를 동시에 실행하고 싶은 파드의 수로 설정함으로써
실행할 파드의 수를 지정할 수 있다. 레플리카가 증가 또는 감소한 경우 또는
파드가 정상적으로 종료되고 교체가 일찍 시작되는 경우라면
언제든지 실행중인 수가 더 높거나 낮을 수 있다.
.spec.replicas 를 지정하지 않으면 기본값은 1이다.
레플리케이션 컨트롤러 사용하기
레플리케이션 컨트롤러와 레플리케이션 컨트롤러의 파드 삭제
레플리케이션 컨트롤러와 레플리케이션의 모든 파드를 삭제하려면 kubectl delete 를 사용하라.
Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를
삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다.
REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후,
레플리케이션 컨트롤러를 삭제).
REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 .spec.selector 가 동일하다면,
새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를
새로운 파드 템플릿과 일치시키려는 노력은 하지 않을 것이다.
새로운 spec에 대한 파드를 제어된 방법으로 업데이트하려면 롤링 업데이트를 사용하라.
레플리케이션 컨트롤러에서 파드 격리
파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅과 데이터 복구를 위해 서비스에서 파드를 제거하는 데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정).
일반적인 사용법 패턴
다시 스케줄하기
위에서 언급했듯이, 실행하려는 파드가 한 개 혹은 1000개이든 관계없이 레플리케이션 컨트롤러는 노드 실패 또는 파드 종료시 지정된 수의 파드가 존재하도록 보장한다 (예 : 다른 제어 에이전트에 의한 동작으로 인해).
스케일링
레플리케이션컨트롤러는 replicas 필드를 업데이트하여, 수동으로 또는 오토 스케일링 제어 에이전트를 통해, 레플리카의 수를 늘리거나 줄일 수 있다.
롤링 업데이트
레플리케이션 컨트롤러는 파드를 하나씩 교체함으로써 서비스에 대한 롤링 업데이트를 쉽게 하도록 설계되었다.
#1353에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다.
이상적으로 롤링 업데이트 컨트롤러는 애플리케이션 준비 상태를 고려하며 주어진 시간에 충분한 수의 파드가 생산적으로 제공되도록 보장할 것이다.
두 레플리케이션 컨트롤러는 일반적으로 롤링 업데이트를 동기화 하는 이미지 업데이트이기 때문에 파드의 기본 컨테이너 이미지 태그와 같이 적어도 하나의 차별화된 레이블로 파드를 생성해야 한다.
다수의 릴리스 트랙
롤링 업데이트가 진행되는 동안 다수의 애플리케이션 릴리스를 실행하는 것 외에도 다수의 릴리스 트랙을 사용하여 장기간에 걸쳐 또는 연속적으로 실행하는 것이 일반적이다. 트랙은 레이블 별로 구분된다.
예를 들어, 서비스는 tier in (frontend), environment in (prod) 이 있는 모든 파드를 대상으로 할 수 있다. 이제 이 계층을 구성하는 10 개의 복제된 파드가 있다고 가정해 보자. 하지만 이 구성 요소의 새로운 버전을 '카나리' 하기를 원한다. 대량의 레플리카에 대해 replicas 를 9로 설정하고 tier=frontend, environment=prod, track=stable 레이블을 설정한 레플리케이션 컨트롤러와, 카나리에 replicas 가 1로 설정된 다른 레플리케이션 컨트롤러에 tier=frontend, environment=prod, track=canary 라는 레이블을 설정할 수 있다. 이제 이 서비스는 카나리와 카나리 이외의 파드 모두를 포함한다. 그러나 레플리케이션 컨트롤러를 별도로 조작하여 테스트하고 결과를 모니터링하는 등의 작업이 혼란스러울 수 있다.
서비스와 레플리케이션컨트롤러 사용
하나의 서비스 뒤에 여러 개의 레플리케이션컨트롤러가 있을 수 있다.
예를 들어 일부 트래픽은 이전 버전으로 이동하고 일부는 새 버전으로 이동한다.
레플리케이션컨트롤러는 자체적으로 종료되지 않지만, 서비스만큼 오래 지속될 것으로 기대되지는 않는다. 서비스는 여러 레플리케이션컨트롤러에 의해 제어되는 파드로 구성될 수 있으며, 서비스 라이프사이클 동안(예를 들어, 서비스를 실행하는 파드 업데이트 수행을 위해) 많은 레플리케이션컨트롤러가 생성 및 제거될 것으로 예상된다. 서비스 자체와 클라이언트 모두 파드를 유지하는 레플리케이션컨트롤러를 의식하지 않는 상태로 남아 있어야 한다.
레플리케이션을 위한 프로그램 작성
레플리케이션 컨트롤러에 의해 생성된 파드는 해당 구성이 시간이 지남에 따라 이질적이 될 수 있지만 균일하고 의미상 동일하도록 설계되었다. 이는 레플리카된 상태 스테이트리스 서버에 적합하지만 레플리케이션 컨트롤러를 사용하여 마스터 선출, 샤드 및 워크-풀 애플리케이션의 가용성을 유지할 수도 있다. RabbitMQ work queues와 같은 애플리케이션은 안티패턴으로 간주되는 각 파드의 구성에 대한 정적/일회성 사용자 정의와 반대로 동적 작업 할당 메커니즘을 사용해야 한다. 리소스의 수직 자동 크기 조정 (예 : CPU 또는 메모리)과 같은 수행된 모든 파드 사용자 정의는 레플리케이션 컨트롤러 자체와 달리 다른 온라인 컨트롤러 프로세스에 의해 수행되어야 한다.
레플리케이션 컨트롤러의 책임
레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 셀렉터와 일치하고 동작하는지를 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 readiness 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다.
레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 (#492에서 논의된)가 레플리케이션 컨트롤러의 replicas 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 spreading)을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 (#170)까지도 고려해야 한다.
레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 Asgard와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
ReplicaSet은 새로운 집합성 기준 레이블 셀렉터이다.
이것은 주로 디플로이먼트에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
디플로이먼트 (권장됨)
Deployment는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
베어 파드
사용자가 직접 파드를 만든 경우와 달리 레플리케이션 컨트롤러는 노드 오류 또는 커널 업그레이드와 같은 장애가 발생하는 노드 유지 관리의 경우와 같이 어떤 이유로든 삭제되거나 종료된 파드를 대체한다. 따라서 애플리케이션에 하나의 파드만 필요한 경우에도 레플리케이션 컨트롤러를 사용하는 것이 좋다. 프로세스 관리자와 비슷하게 생각하면, 단지 단일 노드의 개별 프로세스가 아닌 여러 노드에서 여러 파드를 감독하는 것이다. 레플리케이션 컨트롤러는 로컬 컨테이너가 노드의 에이전트로 (예를 들어 Kubelet 또는 도커 ) 재시작하도록 위임한다.
잡
자체적으로 제거될 것으로 예상되는 파드 (즉, 배치 잡)의 경우
레플리케이션 컨트롤러 대신 Job을 사용하라.
데몬셋
머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신
DaemonSet을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
쿠버네티스를 사용하면 익숙하지 않은 서비스 디스커버리 메커니즘을 사용하기 위해 애플리케이션을 수정할 필요가 없다.
쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고,
그것들 간에 로드-밸런스를 수행할 수 있다.
동기
쿠버네티스 파드는 클러스터 상태와
일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다.
만약 앱을 실행하기 위해 디플로이먼트를 사용한다면,
동적으로 파드를 생성하고 제거할 수 있다.
각 파드는 고유한 IP 주소를 갖지만, 디플로이먼트에서는
한 시점에 실행되는 파드 집합이
잠시 후 실행되는 해당 파드 집합과 다를 수 있다.
이는 다음과 같은 문제를 야기한다. ("백엔드"라 불리는) 일부 파드 집합이
클러스터의 ("프론트엔드"라 불리는) 다른 파드에 기능을 제공하는 경우,
프론트엔드가 워크로드의 백엔드를 사용하기 위해,
프론트엔드가 어떻게 연결할 IP 주소를 찾아서 추적할 수 있는가?
서비스 로 들어가보자.
서비스 리소스
쿠버네티스에서 서비스는 파드의 논리적 집합과 그것들에 접근할 수 있는
정책을 정의하는 추상적 개념이다. (때로는 이 패턴을
마이크로-서비스라고 한다.) 서비스가 대상으로 하는 파드 집합은 일반적으로
셀렉터가 결정한다.
서비스 엔드포인트를 정의하는 다른 방법에 대한 자세한 내용은
셀렉터가 없는 서비스를 참고한다.
예를 들어, 3개의 레플리카로 실행되는 스테이트리스 이미지-처리 백엔드를
생각해보자. 이러한 레플리카는 대체 가능하다. 즉, 프론트엔드는 그것들이 사용하는 백엔드를
신경쓰지 않는다. 백엔드 세트를 구성하는 실제 파드는 변경될 수 있지만,
프론트엔드 클라이언트는 이를 인식할 필요가 없으며, 백엔드 세트 자체를 추적해야 할 필요도
없다.
서비스 추상화는 이러한 디커플링을 가능하게 한다.
클라우드-네이티브 서비스 디스커버리
애플리케이션에서 서비스 디스커버리를 위해 쿠버네티스 API를 사용할 수 있는 경우,
서비스 내 파드 세트가 변경될 때마다 업데이트되는 엔드포인트를 API 서버에
질의할 수 있다.
네이티브 애플리케이션이 아닌 (non-native applications) 경우, 쿠버네티스는 애플리케이션과 백엔드 파드 사이에 네트워크 포트 또는 로드
밸런서를 배치할 수 있는 방법을 제공한다.
서비스 정의
쿠버네티스의 서비스는 파드와 비슷한 REST 오브젝트이다. 모든 REST 오브젝트와
마찬가지로, 서비스 정의를 API 서버에 POST하여
새 인스턴스를 생성할 수 있다.
서비스 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
예를 들어, 각각 TCP 포트 9376에서 수신하고
app=MyApp 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
이 명세는 "my-service"라는 새로운 서비스 오브젝트를 생성하고,
app=MyApp 레이블을 가진 파드의 TCP 9376 포트를 대상으로 한다.
쿠버네티스는 이 서비스에 서비스 프록시가 사용하는 IP 주소 ("cluster IP"라고도 함)
를 할당한다.
(이하 가상 IP와 서비스 프록시 참고)
서비스 셀렉터의 컨트롤러는 셀렉터와 일치하는 파드를 지속적으로 검색하고,
"my-service"라는 엔드포인트 오브젝트에 대한
모든 업데이트를 POST한다.
참고: 서비스는 모든 수신 port를 targetPort에 매핑할 수 있다. 기본적으로 그리고
편의상, targetPort는 port
필드와 같은 값으로 설정된다.
파드의 포트 정의에는 이름이 있고, 서비스의 targetPort 속성에서 이 이름을
참조할 수 있다. 이것은 다른 포트 번호를 통한 가용한 동일 네트워크 프로토콜이 있고,
단일 구성 이름을 사용하는 서비스 내에
혼합된 파드가 존재해도 가능하다.
이를 통해 서비스를 배포하고 진전시키는데 많은 유연성을 제공한다.
예를 들어, 클라이언트를 망가뜨리지 않고, 백엔드 소프트웨어의 다음
버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는
링크-로컬 (IPv4의 경우 169.254.0.0/16와 224.0.0.0/24, IPv6의 경우 fe80::/64)이 되어서는 안된다.
엔드포인트 IP 주소는 다른 쿠버네티스 서비스의 클러스터 IP일 수 없는데,
kube-proxy는 가상 IP를
목적지(destination)로 지원하지 않기 때문이다.
셀렉터가 없는 서비스에 접근하면 셀렉터가 있는 것처럼 동일하게 작동한다.
위의 예에서, 트래픽은 YAML에 정의된 단일 엔드 포인트로
라우팅된다. 192.0.2.42:9376 (TCP)
ExternalName 서비스는 셀렉터가 없고
DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은
이 문서 뒷부분의 ExternalName 섹션을 참조한다.
엔드포인트슬라이스
FEATURE STATE:Kubernetes v1.17 [beta]
엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트슬라이스를
사용하면 여러 리소스에 네트워크 엔드포인트를 분산시킬 수 있다. 기본적으로,
엔드포인트슬라이스는 100개의 엔드포인트에 도달하면 "가득찬 것"로 간주되며,
추가 엔드포인트를 저장하기 위해서는 추가 엔드포인트슬라이스가
생성된다.
엔드포인트슬라이스는 엔드포인트슬라이스에서
자세하게 설명된 추가적인 속성 및 기능을 제공한다.
애플리케이션 프로토콜
FEATURE STATE:Kubernetes v1.20 [stable]
appProtocol 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스
오브젝트에 의해 미러링된다.
이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은
IANA 표준 서비스 이름 또는
mycompany.com/my-custom-protocol과 같은 도메인 접두사 이름 중 하나여야 한다.
가상 IP와 서비스 프록시
쿠버네티스 클러스터의 모든 노드는 kube-proxy를 실행한다. kube-proxy는
ExternalName 이외의 유형의 서비스에 대한
가상 IP 형식을 구현한다.
라운드-로빈 DNS를 사용하지 않는 이유
항상 발생하는 질문은 왜 쿠버네티스가 인바운드 트래픽을 백엔드로 전달하기 위해 프록시에
의존하는가 하는 점이다. 다른 접근법이
있는가? 예를 들어, 여러 A 값 (또는 IPv6의 경우 AAAA)을 가진
DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
취할 수 있는가?
서비스에 프록시를 사용하는 데는 몇 가지 이유가 있다.
레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를
캐싱하는 DNS 구현에 대한 오래된 역사가 있다.
일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다.
앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이
낮거나 0이면 DNS에 부하가 높아 관리하기가
어려워 질 수 있다.
유저 스페이스(User space) 프록시 모드
이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의
추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
연결은 (엔드포인트를 통해 보고된 대로) 서비스의 백엔드 파드 중 하나로 프록시된다.
kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
SessionAffinity 설정을 고려한다.
마지막으로, 유저-스페이스 프록시는 서비스의
clusterIP (가상)와 port 에 대한 트래픽을 캡처하는 iptables 규칙을 설치한다. 이 규칙은
트래픽을 백엔드 파드를 프록시하는 프록시 포트로 리다이렉션한다.
이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스, 엔드포인트 오브젝트의
추가와 제거를 감시한다. 각 서비스에 대해, 서비스의
clusterIP 및 port에 대한 트래픽을 캡처하고 해당 트래픽을 서비스의
백엔드 세트 중 하나로 리다이렉트(redirect)하는
iptables 규칙을 설치한다. 각 엔드포인트 오브젝트에 대해,
백엔드 파드를 선택하는 iptables 규칙을 설치한다.
기본적으로, iptables 모드의 kube-proxy는 임의의 백엔드를 선택한다.
트래픽을 처리하기 위해 iptables를 사용하면 시스템 오버헤드가 줄어드는데, 유저스페이스와
커널 스페이스 사이를 전환할 필요없이 리눅스 넷필터(netfilter)가 트래픽을 처리하기
때문이다. 이 접근 방식은 더 신뢰할 수 있기도 하다.
kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드가
응답하지 않으면, 연결이 실패한다. 이는 userspace 모드와
다르다. 해당 시나리오에서는, kube-proxy는 첫 번째
파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다.
파드 준비성 프로브(readiness probe)를 사용하여
백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는
정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해
실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다.
IPVS 프록시 모드
FEATURE STATE:Kubernetes v1.11 [stable]
ipvs 모드에서는, kube-proxy는 쿠버네티스 서비스와 엔드포인트를 감시하고,
netlink 인터페이스를 호출하여 그에 따라 IPVS 규칙을 생성하고
IPVS 규칙을 쿠버네티스 서비스와 엔드포인트와 주기적으로 동기화한다.
이 제어 루프는 IPVS 상태가 원하는 상태와 일치하도록
보장한다.
서비스에 접근하면, IPVS는 트래픽을 백엔드 파드 중 하나로 보낸다.
IPVS 프록시 모드는 iptables 모드와 유사한 넷필터 후크 기능을
기반으로 하지만, 해시 테이블을 기본 데이터 구조로 사용하고
커널 스페이스에서 동작한다.
이는 IPVS 모드의 kube-proxy는 iptables 모드의 kube-proxy보다
지연 시간이 짧은 트래픽을 리다이렉션하고, 프록시 규칙을 동기화할 때 성능이
훨씬 향상됨을 의미한다. 다른 프록시 모드와 비교했을 때, IPVS 모드는
높은 네트워크 트래픽 처리량도 지원한다.
IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을 제공한다.
다음과 같다.
rr: 라운드-로빈
lc: 최소 연결 (가장 적은 수의 열려있는 연결)
dh: 목적지 해싱
sh: 소스 해싱
sed: 최단 예상 지연 (shortest expected delay)
nq: 큐 미사용 (never queue)
참고:
IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를
사용 가능하도록 해야 한다.
kube-proxy가 IPVS 프록시 모드에서 시작될 때, IPVS 커널 모듈을
사용할 수 있는지 확인한다. IPVS 커널 모듈이 감지되지 않으면, kube-proxy는
iptables 프록시 모드에서 다시 실행된다.
이 프록시 모델에서 클라이언트가 쿠버네티스 또는 서비스 또는 파드에
대해 알지 못하는 경우 서비스의 IP:포트로 향하는 트래픽은
적절한 백엔드로 프록시된다.
특정 클라이언트의 연결이 매번 동일한 파드로
전달되도록 하려면, service.spec.sessionAffinity를 "ClientIP"로 설정하여
클라이언트의 IP 주소를 기반으로 세션 어피니티(Affinity)를 선택할 수 있다.
(기본값은 "None")
service.spec.sessionAffinityConfig.clientIP.timeoutSeconds를 적절히 설정하여
최대 세션 고정 시간을 설정할 수도 있다.
(기본값은 10800으로, 3시간)
멀티-포트 서비스
일부 서비스의 경우, 둘 이상의 포트를 노출해야 한다.
쿠버네티스는 서비스 오브젝트에서 멀티 포트 정의를 구성할 수 있도록 지원한다.
서비스에 멀티 포트를 사용하는 경우, 모든 포트 이름을
명확하게 지정해야 한다.
예를 들면
쿠버네티스의 일반적인 이름과 마찬가지로, 포트 이름은
소문자 영숫자와 - 만 포함해야 한다. 포트 이름은
영숫자로 시작하고 끝나야 한다.
예를 들어, 123-abc 와 web 은 유효하지만, 123_abc 와 -web 은 유효하지 않다.
자신의 IP 주소 선택
서비스 생성 요청시 고유한 클러스터 IP 주소를 지정할 수
있다. 이를 위해, .spec.clusterIP 필드를 설정한다. 예를 들어,
재사용하려는 기존 DNS 항목이 있거나, 특정 IP 주소로 구성되어
재구성이 어려운 레거시 시스템인 경우이다.
선택한 IP 주소는 API 서버에 대해 구성된 service-cluster-ip-range
CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
유효하지 않은 clusterIP 주소 값으로 서비스를 생성하려고 하면, API 서버는
422 HTTP 상태 코드를 리턴하여 문제점이 있음을 알린다.
서비스 디스커버리하기
쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경
변수와 DNS
환경 변수
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
환경 변수 세트를 추가한다. 도커 링크
호환 변수
(makeLinkVariables 참조)와
보다 간단한 {SVCNAME}_SERVICE_HOST 및 {SVCNAME}_SERVICE_PORT 변수를 지원하고,
이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
예를 들어, TCP 포트 6379를 개방하고
클러스터 IP 주소 10.0.0.11이 할당된 서비스 redis-master는,
다음 환경 변수를 생성한다.
서비스에 접근이 필요한 파드가 있고, 환경 변수를
사용해 포트 및 클러스터 IP를 클라이언트 파드에 부여하는
경우, 클라이언트 파드가 생성되기 전에 서비스를 만들어야 한다.
그렇지 않으면, 해당 클라이언트 파드는 환경 변수를 생성할 수 없다.
DNS 만 사용하여 서비스의 클러스터 IP를 검색하는 경우, 이 순서
이슈에 대해 신경 쓸 필요가 없다.
DNS
애드-온을 사용하여 쿠버네티스
클러스터의 DNS 서비스를 설정할 수(대개는 필수적임) 있다.
CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위해 쿠버네티스 API를 감시하고
각각에 대한 DNS 레코드 세트를 생성한다. 클러스터 전체에서 DNS가 활성화된 경우
모든 파드는 DNS 이름으로 서비스를 자동으로
확인할 수 있어야 한다.
예를 들면, 쿠버네티스 네임스페이스 my-ns에 my-service라는
서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여
my-service.my-ns에 대한 DNS 레코드를 만든다. my-ns 네임 스페이스의 파드들은
my-service(my-service.my-ns 역시 동작함)에 대한 이름 조회를
수행하여 서비스를 찾을 수 있어야 한다.
다른 네임스페이스의 파드들은 이름을 my-service.my-ns으로 사용해야 한다. 이 이름은
서비스에 할당된 클러스터 IP로 변환된다.
쿠버네티스는 또한 알려진 포트에 대한 DNS SRV (서비스) 레코드를 지원한다.
my-service.my-ns 서비스에 프로토콜이 TCP로 설정된 http라는 포트가 있는 경우,
IP 주소와 http에 대한 포트 번호를 검색하기 위해 _http._tcp.my-service.my-ns 에 대한
DNS SRV 쿼리를 수행할 수 있다.
쿠버네티스 DNS 서버는 ExternalName 서비스에 접근할 수 있는 유일한 방법이다.
DNS 파드와 서비스에서
ExternalName 검색에 대한 자세한 정보를 찾을 수 있다.
헤드리스(Headless) 서비스
때때로 로드-밸런싱과 단일 서비스 IP는 필요치 않다. 이 경우,
"헤드리스" 서비스라는 것을 만들 수 있는데, 명시적으로
클러스터 IP (.spec.clusterIP)에 "None"을 지정한다.
쿠버네티스의 구현에 묶이지 않고, 헤드리스 서비스를 사용하여
다른 서비스 디스커버리 메커니즘과 인터페이스할 수 있다.
헤드리스 서비스의 경우, 클러스터 IP가 할당되지 않고, kube-proxy가
이러한 서비스를 처리하지 않으며, 플랫폼에 의해 로드 밸런싱 또는 프록시를
하지 않는다. DNS가 자동으로 구성되는 방법은 서비스에 셀렉터가 정의되어 있는지
여부에 달려있다.
셀렉터가 있는 경우
셀렉터를 정의하는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는
API에서 엔드포인트 레코드를 생성하고, DNS 구성을 수정하여
서비스 를 지원하는 파드 를 직접 가리키는 A 레코드(IP 주소)를 반환한다.
셀렉터가 없는 경우
셀렉터를 정의하지 않는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는
엔드포인트 레코드를 생성하지 않는다. 그러나 DNS 시스템은 다음 중 하나를 찾고
구성한다.
애플리케이션 중 일부(예: 프론트엔드)는 서비스를 클러스터 밖에
위치한 외부 IP 주소에 노출하고 싶은 경우가 있을 것이다.
쿠버네티스 ServiceTypes는 원하는 서비스 종류를 지정할 수 있도록 해준다.
기본 값은 ClusterIP이다.
Type 값과 그 동작은 다음과 같다.
ClusterIP: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
클러스터 내에서만 서비스에 도달할 수 있다. 이것은
ServiceTypes의 기본 값이다.
NodePort: 고정 포트 (NodePort)로 각 노드의 IP에 서비스를
노출시킨다. NodePort 서비스가 라우팅되는 ClusterIP 서비스가
자동으로 생성된다. <NodeIP>:<NodePort>를 요청하여,
클러스터 외부에서
NodePort 서비스에 접속할 수 있다.
LoadBalancer: 클라우드 공급자의 로드 밸런서를 사용하여
서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
NodePort와 ClusterIP 서비스가 자동으로 생성된다.
ExternalName: 값과 함께 CNAME 레코드를 리턴하여, 서비스를
externalName 필드의 콘텐츠 (예:foo.bar.example.com)에
매핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.
참고:ExternalName 유형을 사용하려면 kube-dns 버전 1.7 또는
CoreDNS 버전 1.7 이상이 필요하다.
인그레스를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를
노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
NodePort 유형
type 필드를 NodePort로 설정하면, 쿠버네티스 컨트롤 플레인은
--service-node-port-range 플래그로 지정된 범위에서 포트를 할당한다 (기본값 : 30000-32767).
각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
서비스는 할당된 포트를 .spec.ports[*].nodePort 필드에 나타낸다.
포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한
--nodeport-addresses 플래그 또는
kube-proxy 구성 파일의
동등한 nodePortAddresses 필드를
특정 IP 블록으로 설정할 수 있다.
이 플래그는 쉼표로 구분된 IP 블록 목록(예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
예를 들어, --nodeport-addresses=127.0.0.0/8 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. --nodeport-addresses의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
특정 포트 번호를 원한다면, nodePort 필드에 값을 지정할 수
있다. 컨트롤 플레인은 해당 포트를 할당하거나 API 트랜잭션이
실패했다고 보고한다.
이는 사용자 스스로 포트 충돌의 가능성을 고려해야 한다는 의미이다.
또한 NodePort 사용을 위해 구성된 범위 내에 있는, 유효한 포트 번호를
사용해야 한다.
NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설정하거나,
쿠버네티스가 완벽하게 지원하지 못하는 환경을 구성하거나,
하나 이상의 노드 IP를 직접 노출시킬 수 있다.
이 서비스는 <NodeIP>:spec.ports[*].nodePort와
.spec.clusterIP:spec.ports[*].port로 표기된다.
kube-proxy에 대한 --nodeport-addresses 플래그 또는 kube-proxy 구성 파일의
동등한 필드가 설정된 경우, <NodeIP> 는 노드 IP를 필터링한다.
예를 들면
apiVersion:v1kind:Servicemetadata:name:my-servicespec:type:NodePortselector:app:MyAppports:# 기본적으로 그리고 편의상 `targetPort` 는 `port` 필드와 동일한 값으로 설정된다.- port:80targetPort:80# 선택적 필드# 기본적으로 그리고 편의상 쿠버네티스 컨트롤 플레인은 포트 범위에서 할당한다(기본값: 30000-32767)nodePort:30007
로드밸런서 유형
외부 로드 밸런서를 지원하는 클라우드 공급자 상에서, type
필드를 LoadBalancer로 설정하면 서비스에 대한 로드 밸런서를 프로비저닝한다.
로드 밸런서의 실제 생성은 비동기적으로 수행되고,
프로비저닝된 밸런서에 대한 정보는 서비스의
.status.loadBalancer 필드에 발행된다.
예를 들면
외부 로드 밸런서의 트래픽은 백엔드 파드로 전달된다. 클라우드 공급자는 로드 밸런싱 방식을 결정한다.
일부 클라우드 공급자는 loadBalancerIP를 지정할 수 있도록 허용한다. 이 경우, 로드 밸런서는
사용자 지정 loadBalancerIP로 생성된다. loadBalancerIP 필드가 지정되지 않으면,
임시 IP 주소로 loadBalancer가 설정된다. loadBalancerIP를 지정했지만
클라우드 공급자가 이 기능을 지원하지 않는 경우, 설정한 loadbalancerIP 필드는
무시된다.
참고:
Azure 에서 사용자 지정 공개(public) 유형 loadBalancerIP를 사용하려면, 먼저
정적 유형 공개 IP 주소 리소스를 생성해야 한다. 이 공개 IP 주소 리소스는
클러스터에서 자동으로 생성된 다른 리소스와 동일한 리소스 그룹에 있어야 한다.
예를 들면, MC_myResourceGroup_myAKSCluster_eastus이다.
기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든
포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가
지원하는 프로토콜이어야 한다.
kube-apiserver에 대해 기능 게이트 MixedProtocolLBService가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다.
참고: 로드밸런서 서비스 유형에 사용할 수 있는 프로토콜 세트는 여전히 클라우드 제공 업체에서 정의한다.
로드밸런서 NodePort 할당 비활성화
FEATURE STATE:Kubernetes v1.20 [alpha]
v1.20부터는 spec.allocateLoadBalancerNodePorts 필드를 false로 설정하여 서비스 Type=LoadBalancer에
대한 노드 포트 할당을 선택적으로 비활성화 할 수 있다.
노드 포트를 사용하는 대신 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
기본적으로 spec.allocateLoadBalancerNodePorts는 true이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당한다.
노드 포트가 할당된 기존 서비스에서 spec.allocateLoadBalancerNodePorts가 false로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 않는다.
이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 nodePorts 항목을 명시적으로 제거해야 한다.
이 필드를 사용하려면 ServiceLBNodePortControl 기능 게이트를 활성화해야 한다.
내부 로드 밸런서
혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
라우팅해야 하는 경우가 있다.
수평 분할 DNS 환경에서는 외부와 내부 트래픽을 엔드포인트로 라우팅 할 수 있는 두 개의 서비스가 필요하다.
내부 로드 밸런서를 설정하려면, 사용 중인 클라우드 서비스 공급자에 따라
다음의 어노테이션 중 하나를 서비스에 추가한다.
버전 1.3.0 부터, 이 어노테이션의 사용은 ELB에 의해 프록시되는 모든 포트에 적용되며
다르게 구성할 수 없다.
AWS의 ELB 접근 로그
AWS ELB 서비스의 접근 로그를 관리하기 위한 몇 가지 어노테이션이 있다.
service.beta.kubernetes.io/aws-load-balancer-access-log-enabled 어노테이션은
접근 로그의 활성화 여부를 제어한다.
service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval 어노테이션은
접근 로그를 게시하는 간격을 분 단위로 제어한다. 5분 또는 60분의
간격으로 지정할 수 있다.
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name 어노테이션은
로드 밸런서 접근 로그가 저장되는 Amazon S3 버킷의 이름을
제어한다.
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix 어노테이션은
Amazon S3 버킷을 생성한 논리적 계층을 지정한다.
metadata:name:my-serviceannotations:service.beta.kubernetes.io/aws-load-balancer-access-log-enabled:"true"# 로드 밸런서의 접근 로그 활성화 여부를 명시.service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval:"60"# 접근 로그를 게시하는 간격을 분 단위로 제어. 5분 또는 60분의 간격을 지정.service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name:"my-bucket"# 로드 밸런서 접근 로그가 저장되는 Amazon S3 버킷의 이름 명시.service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix:"my-bucket-prefix/prod"# Amazon S3 버킷을 생성한 논리적 계층을 지정. 예: `my-bucket-prefix/prod`
AWS의 연결 드레이닝(Draining)
Classic ELB의 연결 드레이닝은
service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled 어노테이션을
"true"값으로 설정하여 관리할 수 있다. service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout 어노테이션을
사용하여 인스턴스를 해제하기 전에,
기존 연결을 열어 두는 목적으로 최대 시간을 초 단위로 설정할 수도 있다.
이하는 클래식 엘라스틱 로드 밸런서(Classic Elastic Load Balancers)를 관리하기 위한 다른 어노테이션이다.
metadata:name:my-serviceannotations:service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout:"60"# 로드 밸런서가 연결을 닫기 전에, 유휴 상태(연결을 통해 전송 된 데이터가 없음)의 연결을 허용하는 초단위 시간service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled:"true"# 로드 밸런서에 교차-영역(cross-zone) 로드 밸런싱을 사용할 지 여부를 지정service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags:"environment=prod,owner=devops"# 쉼표로 구분된 key-value 목록은 ELB에# 추가 태그로 기록됨service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold:""# 백엔드가 정상인 것으로 간주되는데 필요한 연속적인# 헬스 체크 성공 횟수이다. 기본값은 2이며, 2와 10 사이여야 한다.service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold:"3"# 백엔드가 비정상인 것으로 간주되는데 필요한# 헬스 체크 실패 횟수이다. 기본값은 6이며, 2와 10 사이여야 한다.service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval:"20"# 개별 인스턴스의 상태 점검 사이의# 대략적인 간격 (초 단위). 기본값은 10이며, 5와 300 사이여야 한다.service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout:"5"# 헬스 체크 실패를 의미하는 무 응답의 총 시간 (초 단위)# 이 값은 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval# 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다.service.beta.kubernetes.io/aws-load-balancer-security-groups:"sg-53fae93f"# 생성된 ELB에 추가할 기존 보안 그룹 목록.# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다.service.beta.kubernetes.io/aws-load-balancer-extra-security-groups:"sg-53fae93f,sg-42efd82e"# ELB에 추가될 추가 보안 그룹(security group) 목록service.beta.kubernetes.io/aws-load-balancer-target-node-labels:"ingress-gw,gw-name=public-api"# 로드 밸런서의 대상 노드를 선택하는 데# 사용되는 키-값 쌍의 쉼표로 구분된 목록
AWS의 네트워크 로드 밸런서 지원
FEATURE STATE:Kubernetes v1.15 [beta]
AWS에서 네트워크 로드 밸런서를 사용하려면, nlb 값이 설정된 service.beta.kubernetes.io/aws-load-balancer-type 어노테이션을 사용한다.
참고: NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스턴스 유형 목록은 엘라스틱 로드 밸런싱에 대한 AWS 문서
를 참고한다.
클래식 엘라스틱 로드 밸런서와 달리, 네트워크 로드 밸런서 (NLB)는
클라이언트의 IP 주소를 노드로 전달한다. 서비스의 .spec.externalTrafficPolicy가
Cluster로 설정되어 있으면, 클라이언트의 IP 주소가 종단 파드로
전파되지 않는다.
.spec.externalTrafficPolicy를 Local로 설정하면, 클라이언트 IP 주소가
종단 파드로 전파되지만, 트래픽이 고르지 않게
분배될 수 있다. 특정 로드밸런서 서비스를 위한 파드가 없는 노드는 자동 할당된
.spec.healthCheckNodePort에 의해서 NLB 대상 그룹의
헬스 체크에 실패하고 트래픽을 수신하지 못하게 된다.
클라이언트 트래픽이 NLB 뒤의 인스턴스에 도달하기 위해, 노드 보안
그룹은 다음 IP 규칙으로 수정된다.
규칙
프로토콜
포트
IP 범위
IP 범위 설명
헬스 체크
TCP
NodePort(s) (.spec.healthCheckNodePort for .spec.externalTrafficPolicy = Local)
Subnet CIDR
kubernetes.io/rule/nlb/health=<loadBalancerName>
클라이언트 트래픽
TCP
NodePort(s)
.spec.loadBalancerSourceRanges (defaults to 0.0.0.0/0)
kubernetes.io/rule/nlb/client=<loadBalancerName>
MTU 탐색
ICMP
3,4
.spec.loadBalancerSourceRanges (defaults to 0.0.0.0/0)
kubernetes.io/rule/nlb/mtu=<loadBalancerName>
네트워크 로드 밸런서에 접근할 수 있는 클라이언트 IP를 제한하려면,
loadBalancerSourceRanges를 지정한다.
spec:loadBalancerSourceRanges:- "143.231.0.0/16"
참고:.spec.loadBalancerSourceRanges가 설정되어 있지 않으면, 쿠버네티스는
0.0.0.0/0에서 노드 보안 그룹으로의 트래픽을 허용한다. 노드에 퍼블릭 IP 주소가
있는 경우, 비(non)-NLB 트래픽도 해당 수정된 보안 그룹의
모든 인스턴스에 도달할 수 있다.
Tencent Kubernetes Engine (TKE)의 다른 CLB 어노테이션
아래 표시된 것처럼 TKE에서 클라우드 로드 밸런서를 관리하기 위한 다른 어노테이션이 있다.
metadata:name:my-serviceannotations:# 지정된 노드로 로드 밸런서 바인드service.kubernetes.io/qcloud-loadbalancer-backends-label:key in (value1, value2)# 기존 로드 밸런서의 IDservice.kubernetes.io/tke-existed-lbid：lb-6swtxxxx# 로드 밸런서 (LB)에 대한 사용자 지정 매개 변수는 아직 LB 유형 수정을 지원하지 않음service.kubernetes.io/service.extensiveParameters:""# LB 리스너의 사용자 정의 매개 변수service.kubernetes.io/service.listenerParameters:""# 로드 밸런서 유형 지정# 유효 값 : 클래식 (클래식 클라우드 로드 밸런서) 또는 애플리케이션 (애플리케이션 클라우드 로드 밸런서)service.kubernetes.io/loadbalance-type:xxxxx# 퍼블릭 네트워크 대역폭 청구 방법 지정# 유효 값: TRAFFIC_POSTPAID_BY_HOUR (트래픽 별) 및 BANDWIDTH_POSTPAID_BY_HOUR (대역폭 별)service.kubernetes.io/qcloud-loadbalancer-internet-charge-type:xxxxxx# 대역폭 값 지정 (값 범위 : [1,2000] Mbps).service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out:"10"# 이 어느테이션이 설정되면, 로드 밸런서는 파드가# 실행중인 노드만 등록하고, 그렇지 않으면 모든 노드가 등록됨service.kubernetes.io/local-svc-only-bind-node-with-pod:true
ExternalName 유형
ExternalName 유형의 서비스는 my-service 또는 cassandra와 같은 일반적인 셀렉터에 대한 서비스가 아닌,
DNS 이름에 대한 서비스에 매핑한다. spec.externalName 파라미터를 사용하여 이러한 서비스를 지정한다.
예를 들면, 이 서비스 정의는 prod 네임 스페이스의
my-service 서비스를 my.database.example.com에 매핑한다.
참고: ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
헤드리스(headless) 서비스 사용을 고려한다.
my-service.prod.svc.cluster.local 호스트를 검색하면, 클러스터 DNS 서비스는
my.database.example.com 값의 CNAME 레코드를 반환한다. my-service에 접근하는 것은
다른 서비스와 같은 방식으로 작동하지만, 리다이렉션은 프록시 또는
포워딩을 통하지 않고 DNS 수준에서 발생한다는 중요한
차이점이 있다. 나중에 데이터베이스를 클러스터로 이동하기로 결정한 경우, 해당
파드를 시작하고 적절한 셀렉터 또는 엔드포인트를 추가하고,
서비스의 유형(type)을 변경할 수 있다.
경고:
HTTP 및 HTTPS를 포함한, 몇몇 일반적인 프로토콜에 ExternalName을 사용하는 것은 문제가 있을 수 있다. ExternalName을 사용하는 경우, 클러스터 내부의 클라이언트가 사용하는 호스트 이름(hostname)이 ExternalName이 참조하는 이름과 다르다.
호스트 이름을 사용하는 프로토콜의 경우, 이러한 차이로 인해 오류가 발생하거나 예기치 않은 응답이 발생할 수 있다. HTTP 요청에는 오리진(origin) 서버가 인식하지 못하는 Host : 헤더가 있다. TLS 서버는 클라이언트가 연결된 호스트 이름과 일치하는 인증서를 제공할 수 없다.
하나 이상의 클러스터 노드로 라우팅되는 외부 IP가 있는 경우, 쿠버네티스 서비스는 이러한
externalIPs에 노출될 수 있다. 서비스 포트에서 외부 IP (목적지 IP)를 사용하여 클러스터로 들어오는 트래픽은
서비스 엔드포인트 중 하나로 라우팅된다. externalIPs는 쿠버네티스에 의해 관리되지 않으며
클러스터 관리자에게 책임이 있다.
서비스 명세에서, externalIPs는 모든 ServiceTypes와 함께 지정할 수 있다.
아래 예에서, 클라이언트는 "80.11.12.10:80"(외부 IP:포트)로 "my-service"에 접근할 수 있다.
VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일에서는 동작하지만, 수천 개의
서비스가 포함된 대규모 클러스터로는 확장되지 않는다.
포털에 대한 독창적인 설계 제안에 이에 대한 자세한 내용이
있다.
유저스페이스 프록시를 사용하면 서비스에 접근하는 패킷의 소스 IP 주소가
가려진다.
이것은 일종의 네트워크 필터링 (방화벽)을 불가능하게 만든다. iptables
프록시 모드는 클러스터 내
소스 IP를 가리지 않지만, 여전히 로드 밸런서 또는 노드-포트를 통해 오는
클라이언트에 영향을 미친다.
Type 필드는 중첩된 기능으로 설계되었다. - 각 레벨은 이전 레벨에
추가된다. 이는 모든 클라우드 공급자에 반드시 필요한 것은 아니지만, (예: Google Compute Engine는
LoadBalancer를 작동시키기 위해 NodePort를 할당할 필요는 없지만, AWS는 필요하다)
현재 API에는 필요하다.
가상 IP 구현
서비스를 사용하려는 많은 사람들에게 이전 정보가
충분해야 한다. 그러나, 이해가 필요한 부분 뒤에는
많은 일이 있다.
충돌 방지
쿠버네티스의 주요 철학 중 하나는 잘못한 것이
없는 경우 실패할 수 있는 상황에 노출되어서는
안된다는 것이다. 서비스 리소스 설계 시, 다른 사람의 포트 선택과
충돌할 경우에 대비해 자신의 포트 번호를 선택하지
않아도 된다. 그것은 격리 실패이다.
서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 두 개의
서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를
할당하여 이를 수행한다.
각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는
각 서비스를 만들기 전에 etcd에서
글로벌 할당 맵을 원자적으로(atomically) 업데이트한다. 서비스가 IP 주소 할당을 가져오려면
레지스트리에 맵 오브젝트가 있어야 하는데, 그렇지 않으면
IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다.
컨트롤 플레인에서, 백그라운드 컨트롤러는 해당 맵을
생성해야 한다. (인-메모리 잠금을 사용하는 이전 버전의 쿠버네티스에서 마이그레이션
지원 필요함) 쿠버네티스는 또한 컨트롤러를 사용하여 유효하지 않은
할당 (예: 관리자 개입으로)을 체크하고 더 이상 서비스에서 사용하지 않는 할당된
IP 주소를 정리한다.
서비스 IP 주소
실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리,
서비스 IP는 실제로 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는
iptables (리눅스의 패킷 처리 로직)를 필요에 따라
명백하게 리다이렉션되는 가상 IP 주소를 정의하기 위해 사용한다. 클라이언트가 VIP에
연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다.
환경 변수와 서비스 용 DNS는 실제로 서비스의
가상 IP 주소 (및 포트)로 채워진다.
kube-proxy는 조금씩 다르게 작동하는 세 가지 프록시 모드—유저스페이스, iptables and IPVS—를
지원한다.
유저스페이스 (Userspace)
예를 들어, 위에서 설명한 이미지 처리 애플리케이션을 고려한다.
백엔드 서비스가 생성되면, 쿠버네티스 마스터는 가상
IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정하면, 서비스는
클러스터의 모든 kube-proxy 인스턴스에서 관찰된다.
프록시가 새 서비스를 발견하면, 새로운 임의의 포트를 열고, 가상 IP 주소에서
이 새로운 포트로 iptables 리다이렉션을 설정한 후,
연결을 수락하기 시작한다.
클라이언트가 서비스의 가상 IP 주소에 연결하면, iptables
규칙이 시작되고, 패킷을 프록시의 자체 포트로 리다이렉션한다.
"서비스 프록시"는 백엔드를 선택하고, 클라이언트에서 백엔드로의 트래픽을 프록시하기 시작한다.
이는 서비스 소유자가 충돌 위험 없이 원하는 어떤 포트든 선택할 수 있음을
의미한다. 클라이언트는 실제로 접근하는 파드를 몰라도, IP와 포트에
연결할 수 있다.
iptables
다시 한번, 위에서 설명한 이미지 처리 애플리케이션을 고려한다.
백엔드 서비스가 생성되면, 쿠버네티스 컨트롤 플레인은 가상
IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정하면, 서비스는
클러스터의 모든 kube-proxy 인스턴스에서 관찰된다.
프록시가 새로운 서비스를 발견하면, 가상 IP 주소에서 서비스-별 규칙으로
리다이렉션되는 일련의 iptables 규칙을 설치한다. 서비스-별
규칙은 트래픽을 (목적지 NAT를 사용하여) 백엔드로 리다이렉션하는 엔드포인트-별 규칙에
연결한다.
클라이언트가 서비스의 가상 IP 주소에 연결하면 iptables 규칙이 시작한다.
(세션 어피니티(Affinity)에 따라 또는 무작위로) 백엔드가 선택되고 패킷이
백엔드로 리다이렉션된다. 유저스페이스 프록시와 달리, 패킷은 유저스페이스로
복사되지 않으며, 가상 IP 주소가 작동하기 위해 kube-proxy가
실행 중일 필요는 없으며, 노드는 변경되지 않은 클라이언트 IP 주소에서 오는
트래픽을 본다.
트래픽이 노드-포트 또는 로드 밸런서를 통해 들어오는 경우에도,
이와 동일한 기본 흐름이 실행되지만, 클라이언트 IP는 변경된다.
IPVS
iptables 작업은 대규모 클러스터 (예: 10,000 서비스)에서 크게 느려진다.
IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이블을 기반으로 한다. 따라서 IPVS 기반 kube-proxy로부터 많은 개수의 서비스에서 일관성 있는 성능을 가질 수 있다. 한편, IPVS 기반 kube-proxy는 보다 정교한 로드 밸런싱 알고리즘 (least conns, locality, weighted, persistence)을 가진다.
API 오브젝트
서비스는 쿠버네티스 REST API의 최상위 리소스이다. API 오브젝트에 대한
자세한 내용은 다음을 참고한다. 서비스 API 오브젝트
지원되는 프로토콜
TCP
모든 종류의 서비스에 TCP를 사용할 수 있으며, 이는 기본 네트워크 프로토콜이다.
UDP
대부분의 서비스에 UDP를 사용할 수 있다. type=LoadBalancer 서비스의 경우, UDP 지원은
이 기능을 제공하는 클라우드 공급자에 따라 다르다.
SCTP
FEATURE STATE:Kubernetes v1.20 [stable]
SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우 대부분의 서비스에 SCTP를 사용할 수 있다.
type=LoadBalancer 서비스의 경우 SCTP 지원은 이 기능을 제공하는
클라우드 공급자에 따라 다르다. (대부분 그렇지 않음)
경고
멀티홈드(multihomed) SCTP 연결을 위한 지원
경고:
멀티홈 SCTP 연결을 위해서는 먼저 CNI 플러그인이 파드에 대해 멀티 인터페이스 및 IP 주소 할당이 지원되어야 한다.
멀티홈 SCTP 연결을 위한 NAT는 해당 커널 모듈 내에 특수한 로직을 필요로 한다.
윈도우
경고: SCTP는 윈도우 기반 노드를 지원하지 않는다.
유저스페이스 kube-proxy
경고: kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
HTTP
클라우드 공급자가 이를 지원하는 경우, LoadBalancer 모드의
서비스를 사용하여 서비스의 엔드포인트로 전달하는 외부 HTTP / HTTPS 리버스 프록시를
설정할 수 있다.
서비스 토폴로지 를 활성화 하면 서비스는 클러스터의 노드 토폴로지를
기반으로 트래픽을 라우팅한다. 예를 들어, 서비스는 트래픽을
클라이언트와 동일한 노드이거나 동일한 가용성 영역에 있는 엔드포인트로
우선적으로 라우팅되도록 지정할 수 있다.
소개
기본적으로 ClusterIP 또는 NodePort 서비스로 전송된 트래픽은 서비스의
모든 백엔드 주소로 라우팅 될 수 있다. 쿠버네티스 1.7부터는 "외부(external)"
트래픽을 수신한 노드에서 실행중인 파드로 라우팅할 수 있었지만,
ClusterIP 서비스에서는 지원되지 않으며 더 복잡한
토폴로지 — 영역별 라우팅과 같은 — 에서는 불가능 했다.
서비스 토폴로지 기능은 서비스 생성자가 발신 노드와 수신 노드에 대해서
노드 레이블에 기반한 트래픽 라우팅 정책을 정의할 수 있도록
함으로써 이 문제를 해결한다.
소스와 목적지의 노드 레이블 일치를 사용하여 운영자는 운영자의 요구 사항에
적합한 메트릭에 대해서 서로 "근접(closer)" 하거나 "먼(farther)"
노드 그룹을 지정할 수 있다. 공용 클라우드의 많은 운영자들이 서비스 트래픽을
동일한 영역에서 유지하는 것을 선호하는 것을 필요성의 예제로 볼 수 있다. 그 이유는
지역간의 트래픽에는 관련 비용이 발생하지만 지역 내의 트래픽은 발생하지 않기 때문이다.
다른 일반적인 필요성으로는 DaemonSet이 관리하는 로컬 파드로
트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에
연결된 노드로 트래픽을 유지하는 것이 있다.
서비스 토폴로지 사용하기
만약 클러스터에서 서비스 토폴로지가 활성화된 경우, 서비스 사양에서
topologyKeys 필드를 지정해서 서비스 트래픽 라우팅을 제어할 수 있다. 이 필드는
이 서비스에 접근할 때 엔드포인트를 정렬하는데 사용되는 노드
레이블의 우선 순위 목록이다. 트래픽은 첫 번째 레이블 값이 해당 레이블의
발신 노드 값과 일치하는 노드로 보내진다. 만약 노드에 서비스와 일치하는
백엔드가 없는 경우, 두 번째 레이블을 그리고 더 이상의
레이블이 남지 않을 때까지 고려한다.
만약 일치하는 것을 찾지 못한 경우에는, 마치 서비스에 대한 백엔드가 없는 것처럼
트래픽이 거부될 것이다. 즉, 엔드포인트는 사용 가능한 백엔드가 있는 첫 번째
토폴로지 키를 기반으로 선택된다. 만약 이 필드가 지정되고 모든 항목에
클라이언트의 토폴로지와 일치하는 백엔드가 없는 경우, 서비스에는 해당 클라이언트에
대한 백엔드가 없기에 연결에 실패해야 한다. 특수한 값인 "*" 은 "모든 토폴로지"를
의미하는데 사용될 수 있다. 이 캐치 올(catch-all) 값을 사용하는 경우
목록의 마지막 값으로만 타당하다.
만약 topologyKeys 가 지정되지 않거나 비어있는 경우 토폴로지 제약 조건이 적용되지 않는다.
호스트 이름, 영역 이름 그리고 지역 이름으로 레이블이 지정된 노드가 있는
클러스터가 있다고 생각해 보자. 그러고 나면, 서비스의 topologyKeys 값을 설정해서 다음과 같이 트래픽을
전달할 수 있다.
동일한 노드의 엔드포인트에만 해당하고, 엔드포인트가 노드에 없으면 실패한다:
["kubernetes.io/hostname"].
동일한 노드의 엔드포인트를 선호하지만, 동일한 영역의 엔드포인트로 대체
한 후 동일한 지역으로 대체되고, 그렇지 않으면 실패한다: ["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"].
예를 들어 데이터 위치가 중요한 경우에 유용할 수 있다.
동일한 영역이 선호되지만, 이 영역 내에 사용할 수 있는 항목이 없는 경우에는
사용가능한 엔드포인트로 대체된다:
["topology.kubernetes.io/zone", "*"].
제약들
서비스 토폴로지는 externalTrafficPolicy=Local 와 호환되지 않으므로
서비스는 이 두 가지 기능을 함께 사용할 수 없다. 동일한 서비스가 아닌
같은 클러스터의 다른 서비스라면 이 기능을 함께 사용할
수 있다.
유효한 토폴로지 키는 현재 kubernetes.io/hostname,
topology.kubernetes.io/zone 그리고 topology.kubernetes.io/region 로
제한되어있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
토폴로지 키는 유효한 레이블 키이어야 하며 최대 16개의 키를 지정할 수 있다.
만약 캐치 올(catch-all) 값인 "*" 를 사용한다면 토폴로지 키들의 마지막 값이어야
한다.
예시들
다음은 서비스 토폴로지 기능을 사용하는 일반적인 예시이다.
노드 로컬 엔드포인트만
노드 로컬 엔드포인트로만 라우팅하는 서비스이다. 만약 노드에 엔드포인트가 없으면 트레픽이 드롭된다.
쿠버네티스는 파드와 서비스를 위한 DNS 레코드를 생성한다. 사용자는 IP 주소 대신에
일관된 DNS 네임을 통해서 서비스에 접속할 수 있다.
소개
쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며,
개별 컨테이너들이 DNS 네임을 해석할 때
DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다.
기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와
클러스터의 기본 도메인을 포함한다.
서비스의 네임스페이스
DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다른 결과를 반환할 수
있다. 네임스페이스를 지정하지 않은 DNS 쿼리는 파드의 네임스페이스에
국한된다. DNS 쿼리에 네임스페이스를 명시하여 다른 네임스페이스에 있는 서비스에 접속한다.
예를 들어, test 네임스페이스에 있는 파드를 생각해보자. data 서비스는
prod 네임스페이스에 있다.
이 경우, data 에 대한 쿼리는 파드의 test 네임스페이스를 사용하기 때문에 결과를 반환하지 않을 것이다.
data.prod 로 쿼리하면 의도한 결과를 반환할 것이다. 왜냐하면
네임스페이스가 명시되어 있기 때문이다.
DNS 쿼리는 파드의 /etc/resolv.conf 를 사용하여 확장될 수 있을 것이다. Kubelet은
각 파드에 대해서 파일을 설정한다. 예를 들어, data 만을 위한 쿼리는
data.test.cluster.local 로 확장된다. search 옵션의 값은
쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우,
resolv.conf 설명 페이지.를 참고한다.
요약하면, test 네임스페이스에 있는 파드는 data.prod 또는
data.prod.cluster.local 중 하나를 통해 성공적으로 해석될 수 있다.
DNS 레코드
어떤 오브젝트가 DNS 레코드를 가지는가?
서비스
파드
다음 섹션은 지원되는 DNS 레코드의 종류 및 레이아웃에 대한 상세
내용이다. 혹시 동작시킬 필요가 있는 다른 레이아웃, 네임, 또는 쿼리는
구현 세부 사항으로 간주되며 경고 없이 변경될 수 있다.
최신 명세 확인을 위해서는,
쿠버네티스 DNS-기반 서비스 디스커버리를 본다.
서비스
A/AAAA 레코드
"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라
my-svc.my-namespace.svc.cluster-domain.example
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터
IP로 해석된다.
"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라
my-svc.my-namespace.svc.cluster-domain.example
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다.
노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다.
클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을
통해 선택할 수 있다.
SRV 레코드
SRV 레코드는 노멀 서비스 또는
헤드리스 서비스에
속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다.
_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example.
정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다.
my-svc.my-namespace.svc.cluster-domain.example.
헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의
포트 번호와 도메인 이름을 포함한다.
auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example.
파드 스펙(Pod spec)에는 선택적 필드인 hostname이 있다.
이 필드는 파드의 호스트네임을 지정할 수 있다.
hostname 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다.
예를 들어 hostname 필드가 "my-host"로 설정된 파드는 호스트네임이 "my-host"로 설정된다.
또한, 파드 스펙에는 선택적 필드인 subdomain이 있다. 이 필드는 서브도메인을 지정할 수 있다.
예를 들어 "my-namespace" 네임스페이스에서, hostname 필드가 "foo"로 설정되고,
subdomain 필드가 "bar"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다.
"foo.bar.my-namespace.svc.cluster-domain.example".
파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면,
클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다.
예를 들어 호스트네임이 "busybox-1"이고,
서브도메인이 "default-subdomain"이고,
같은 네임스페이스 내 헤드리스 서비스의 이름이 "default-subdomain"이면,
파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다.
"busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example".
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
"busybox1"와 "busybox2" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.
엔드포인트 오브젝트는 hostname 필드를
임의의 엔드포인트 IP 주소로 지정할 수 있다.
참고: A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에
파드의 A 또는 AAAA 레코드를 생성하기 위해서는 hostname 필드를 작성해야 한다.
hostname 필드는 없고 subdomain 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의
A 또는 AAAA 레코드만 생성할 수 있다. (default-subdomain.my-namespace.svc.cluster-domain.example)
또한 서비스에서 publishNotReadyAddresses=True 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다.
파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 hostname 명령어는 busybox-1 을 반환하고 hostname --fqdn 명령은 FQDN을 반환한다.
파드 명세에서 setHostnameAsFQDN: true 를 설정하면, kubelet은 파드의 FQDN을 해당 파드 네임스페이스의 호스트네임에 기록한다. 이 경우, hostname 과 hostname --fqdn 은 모두 파드의 FQDN을 반환한다.
참고:
리눅스에서, 커널의 호스트네임 필드(struct utsname 의 nodename 필드)는 64자로 제한된다.
파드에서 이 기능을 사용하도록 설정하고 FQDN이 64자보다 길면, 시작되지 않는다. 파드는 파드 호스트네임과 클러스터 도메인에서 FQDN을 구성하지 못한다거나, FQDN long-FDQN 이 너무 길다(최대 64자, 70자 요청인 경우)와 같은 오류 이벤트를 생성하는 Pending 상태(kubectl 에서 표시하는 ContainerCreating)로 유지된다. 이 시나리오에서 사용자 경험을 개선하는 한 가지 방법은 사용자가 최상위 레벨을 오브젝트(예를 들어, 디플로이먼트)를 생성할 때 FQDN 크기를 제어하기 위해 어드미션 웹훅 컨트롤러를 생성하는 것이다.
파드의 DNS 정책
DNS 정책은 파드별로 설정할 수 있다.
현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다.
이 정책들은 파드 스펙의 dnsPolicy 필드에서 지정할 수 있다.
"Default": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다.
자세한 내용은
관련 논의에서
확인할 수 있다.
"ClusterFirst": "www.kubernetes.io"와 같이 클러스터 도메인 suffix 구성과
일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다.
클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다.
그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은
관련 논의에서
확인할 수 있다.
"ClusterFirstWithHostNet": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
"ClusterFirstWithHostNet"을 명시적으로 설정해야 한다.
"None": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
모든 DNS 설정은 파드 스펙 내에 dnsConfig필드를 사용하여 제공해야 한다.
아래 절인 파드의 DNS 설정에서
자세한 내용을 확인할 수 있다.
참고: "Default"는 기본 DNS 정책이 아니다. dnsPolicy가 명시적으로 지정되어있지 않다면
"ClusterFirst"가 기본값으로 사용된다.
아래 예시는 hostNetwork필드가 true로 설정되어 있어서
DNS 정책이 "ClusterFirstWithHostNet"으로 설정된 파드를 보여준다.
dnsConfig 필드는 선택적이고, dnsPolicy 세팅과 함께 동작한다.
이때, 파드의 dnsPolicy의 값이 "None"으로 설정되어 있어야
dnsConfig 필드를 지정할 수 있다.
사용자는 dnsConfig 필드에서 다음과 같은 속성들을 지정할 수 있다.
nameservers: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다.
파드의 dnsPolicy가 "None" 으로 설정된 경우에는
적어도 하나의 IP 주소가 포함되어야 하며,
그렇지 않으면 이 속성은 생략할 수 있다.
nameservers에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며
중복되는 주소는 제거된다.
searches: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다.
이 속성은 생략이 가능하며,
값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다.
병합 시 중복되는 도메인은 제거되며,
쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
options: name 속성(필수)과 value 속성(선택)을 가질 수 있는 오브젝트들의 선택적 목록이다.
이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다.
이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며,
병합 시 중복되는 항목은 제거된다.
지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다. 쿠버네티스의 네트워킹 접근 방식을 논의하기 전에, 도커와 함께 동작하는 "일반적인" 네트워킹 방법과 대조해볼 가치가 있다.
기본적으로 도커는 호스트-프라이빗 네트워킹을 사용하기에 컨테이너는 동일한 머신에 있는 경우에만 다른 컨테이너와 통신 할 수 있다. 도커 컨테이너가 노드를 통해 통신하려면 머신 포트에 IP 주소가 할당되어야 컨테이너에 전달되거나 프록시된다. 이것은 컨테이너가 사용하는 포트를 매우 신중하게 조정하거나 포트를 동적으로 할당해야 한다는 의미이다.
컨테이너를 제공하는 여러 개발자 또는 팀에서 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다.
파드를 클러스터에 노출하기
이 작업은 이전 예시에서 수행해 보았지만, 네트워킹 관점을 중점에 두고 다시 한번 수행해 보자.
nginx 파드를 생성하고, 해당 파드에 컨테이너 포트 사양이 있는 것을 참고한다.
클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 않으며 , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.
평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다.
쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
kubectl expose 를 사용해서 2개의 nginx 레플리카에 대한 서비스를 생성할 수 있다.
이 사양은 run: my-nginx 레이블이 부착된 모든 파드에 TCP 포트 80을
대상으로 하는 서비스를 만들고 추상화된 서비스 포트에 노출시킨다
(targetPort 는 컨테이너가 트래픽을 수신하는 포트, port 는
추상화된 서비스 포트로 다른 파드들이 서비스에 접속하기위해 사용하는
모든 포트일 수 있다).
서비스의
API 오브젝트를 보고 서비스 정의에서 지원되는 필드 목록을 확인한다.
서비스를 확인한다.
kubectl get svc my-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx ClusterIP 10.0.162.149 <none> 80/TCP 21s
앞에서 언급한 바와 같이, 서비스는 파드 그룹에 의해 지원된다. 이 파드들은
endpoints 를 통해 노출된다. 서비스 셀렉터는 지속적으로 평가되고
결과는 my-nginx 이름의 엔드포인트 오브젝트에 POST된다.
파드가 죽으면 자동적으로 엔드포인트에서 제거되며 서비스 셀렉터와
일치하는 새 파드는 자동적으로 엔드포인트에 추가된다.
엔드포인트를 확인하고 IP가 첫 번째 단계에서 생성된 파드와 동일하다는
점을 참고한다.
NAME ENDPOINTS AGE
my-nginx 10.244.2.5:80,10.244.3.4:80 1m
이제 클러스터의 모든 노드에서 <CLUSTER-IP>:<PORT> 로 nginx 서비스를
curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외부에서는 절대로 연결되지
않음에 참고한다. 만약 이것이 어떻게 작동하는지 궁금하다면
서비스 프록시에 대해 더 읽어본다.
서비스에 접근하기
쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
지원한다. 전자는 기본적으로 작동하지만 후자는
CoreDNS 클러스터 애드온이 필요하다.
참고: 만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) 파드 사양에서
enableServiceLinks 플래그를 false 로 설정하면 이 모드를 비활성화할 수 있다.
환경 변수들
파드가 노드에서 실행될 때 kubelet은 각기 활성화된 서비스에 대해 일련의 환경
변수 집합을 추가한다. 이것은 순서 문제를 야기한다. 이유를 확인하려면
실행 중인 nginx 파드 환경을 점검해야 한다(실제 사용자의 파드 이름은 다를 것이다).
kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
서비스에 대한 언급이 없다는 것에 참고해야 한다. 이것은 서비스 이전에 레플리카를
생성했기 때문이다. 이 작업을 수행할 때 또 다른 단점은 스케줄러가 두 파드를
모두 동일한 머신에 배치할 수도 있다는 것이며, 이로 인해 전체 서비스가 중단될 수
있다. 두개의 파드를 죽이고 디플로이먼트가 파드를 재생성하기를 기다리는 것으로
이를 정상화 할 수 있다. 이번에는 서비스가 레플리카들 전 에
존재한다. 이렇게 하면 올바른 환경 변수뿐만 아니라 파드의 스케줄러-수준의
서비스 분배(모든 노드에 동일한 용량이 제공되는 경우)가
된다.
쿠버네티스는 DNS 클러스터 애드온 서비스를 제공하며 dns 이름을 다른 서비스에 자동으로 할당한다. 다음 명령어로 이것이 클러스터에서 실행 중인지 확인할 수 있다.
kubectl get services kube-dns --namespace=kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 8m
이 섹션의 나머지 부분에서는 수명이 긴 IP의 서비스(my-nginx)와 이 IP
에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 kube-dns)을 사용하므로, 표준 방법(예: gethostbyname())을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 CoreDNS README 또는 CoreDNS 설치를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다.
kubectl run curl --image=radial/busyboxplus:curl -i --tty
Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
Hit enter for command prompt
kubectl get pods -o yaml | grep -i podip
podIP: 10.244.3.5
node $ curl -k https://10.244.3.5
...
<h1>Welcome to nginx!</h1>
마지막 단계에서 curl에 -k 파라미터를 제공한 방법에 참고한다. 이는 인증서 생성시 nginx를 실행하는 파드에 대해 아무것도 모르기 때문에
curl에 CName 불일치를 무시하도록 지시해야하기 때문이다. 서비스를 생성해서 인증서에 사용된 CName을 서비스 조회시 파드에서 사용된 실제 DNS 이름과 연결했다.
파드에서 이것을 테스트 해보자(단순히 동일한 시크릿이 재사용되고 있으며, 파드는 서비스에 접근하기위해 nginx.crt만 필요하다).
애플리케이션의 일부인 경우 원한다면 외부 IP 주소에 서비스를
노출할 수 있다. 쿠버네티스는 이를 수행하는 2가지 방법인 NodePorts와
LoadBalancers를지원한다. 마지막 섹션에서 생성된 서비스는 이미 NodePort 를 사용했기에
노드에 공용 IP가 있는경우 nginx HTTPS 레플리카가 인터넷 트래픽을 처리할
준비가 되어있다.
이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성한다. my-nginx 서비스의 Type 을 NodePort 에서 LoadBalancer 로 변경한다.
kubectl edit svc my-nginx
kubectl get svc my-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s
curl https://<EXTERNAL-IP> -k
...
<title>Welcome to nginx!</title>
EXTERNAL-IP 의 IP 주소는 공용 인터넷에서 이용할 수 있는 주소이다. CLUSTER-IP 는
클러스터/프라이빗 클라우드 네트워크 내에서만 사용할 수 있다.
AWS에서는 LoadBalancer 유형은 IP가 아닌 (긴)호스트네임을 사용하는 ELB를
생성한다는 점을 참고한다. 이것은 일반적인 kubectl get svc 의 출력에
맞추기에는 매우 길기 때문에 실제로 이를 보려면 kubectl describe service my-nginx 를
수행해야 한다. 다음과 같은 것을 보게 된다.
kubectl describe service my-nginx
...
LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
...
엔드포인트슬라이스 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
대안을 제안한다.
사용동기
엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
서비스가 더 많은 수의 백엔드 파드로
더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
되었다.
특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
어려움이 있었다.
이후로 서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트
리소스에 저장되기 때문에 엔드포인트 리소스가 상당히 커질 수 있다. 이것은 쿠버네티스
구성요소 (특히 마스터 컨트롤 플레인)의 성능에 영향을 미쳤고
엔드포인트가 변경될 때 상당한 양의 네트워크 트래픽과 처리를 초래했다.
엔드포인트슬라이스는 이러한 문제를 완화하고 토폴로지 라우팅과
같은 추가 기능을 위한 확장 가능한 플랫폼을 제공한다.
엔드포인트슬라이스 리소스
쿠버네티스에서 엔드포인트슬라이스는 일련의 네트워크 엔드포인트에 대한
참조를 포함한다. 쿠버네티스 서비스에 셀렉터가 지정되면 컨트롤 플레인은 자동으로
엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는
프로토콜, 포트 번호 및 서비스 이름의 고유한 조합을 통해 네트워크 엔드포인트를
그룹화한다.
엔드포인트슬라이스 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
예를 들어, 여기에 example 쿠버네티스 서비스를 위한 엔드포인트슬라이스
리소스 샘플이 있다.
기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를
갖도록 엔드포인트슬라이스를
생성하고 관리한다. --max-endpoints-per-slicekube-controller-manager
플래그를 사용하여, 최대 1000개까지 구성할 수 있다.
엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해
kube-proxy에
신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
서비스에 대해 성능 향상을 제공해야 한다.
주소 유형
엔드포인트슬라이스는 다음 주소 유형을 지원한다.
IPv4
IPv6
FQDN (전체 주소 도메인 이름)
조건
엔드포인트슬라이스 API는 컨슈머에게 유용한 엔드포인트에 대한 조건을 저장한다.
조건은 준비, 제공 및 종료 세 가지가 있다.
준비
ready는 파드의 Ready 조건에 매핑되는 조건이다. Ready 조건이 True로 설정된 실행 중인 파드는
이 엔드포인트슬라이스 조건도 true로 설정되어야 한다. 호환성의
이유로, 파드가 종료될 때 ready는 절대 true가 되면 안 된다. 컨슈머는 serving 조건을 참조하여
파드 종료 준비 상태(readiness)를 검사해야 한다.
이 규칙의 유일한 예외는 spec.publishNotReadyAddresses가 true로 설정된 서비스이다.
이러한 서비스의 엔드 포인트는 항상 ready조건이 true로 설정된다.
제공(Serving)
FEATURE STATE:Kubernetes v1.20 [alpha]
serving은 종료 상태를 고려하지 않는다는 점을 제외하면 ready 조건과 동일하다.
엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면
이 조건을 확인해야 한다.
참고:serving은 ready와 거의 동일하지만 ready의 기존 의미가 깨지는 것을 방지하기 위해 추가되었다.
엔드포인트를 종료하기 위해 ready가 true 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다.
역사적으로 종료된 엔드포인트는 처음부터 엔드포인트 또는 엔드포인트슬라이스 API에 포함되지 않았기 때문이다.
이러한 이유로 ready는 엔드포인트 종료를 위해 alwaysfalse이며,
클라이언트가 ready에 대한 기존 의미와 관계없이 파드 종료 준비 상태를
추적 할 수 있도록 v1.20에 새로운 조건 serving이 추가되었다.
종료(Terminating)
FEATURE STATE:Kubernetes v1.20 [alpha]
종료(Terminating)는 엔드포인트가 종료되는지 여부를 나타내는 조건이다.
파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다.
토폴로지 정보
FEATURE STATE:Kubernetes v1.20 [deprecated]
참고: 엔드포인트슬라이스의 토폴로지 필드는 사용 중단되었으며 향후 릴리스에서 제거된다.
토폴로지에서 kubernetes.io/hostname을 설정하는 대신 새로운 nodeName 필드가
사용된다. 영역 및 리전을 커버하는 다른 토폴로지 필드는
엔드포인트슬라이스 내의 모든 엔드포인트에 적용되는
엔드포인트슬라이스 레이블을 이용해 더 잘 표현될 수 있다.
엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다.
이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된
엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면,
컨트롤 플레인은 엔드포인트슬라이스에 대해 다음의 토폴로지 레이블을 설정한다.
kubernetes.io/hostname - 이 엔드포인트가 있는 노드의 이름.
topology.kubernetes.io/zone - 이 엔드포인트가 있는 영역의 이름.
topology.kubernetes.io/region - 이 엔드포인트가 있는 지역의 이름.
이런 레이블 값은 슬라이스의 각 엔드포인트와 연관된 리소스에서
파생된다. 호스트 이름 레이블은 해당 파드의
NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당
노드에서 이름이 같은 값을 나타낸다.
관리
대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스
컨트롤러)는
엔드포인트슬라이스 오브젝트를 생성하고 관리한다. 다른 엔티티나 컨트롤러가 추가
엔드포인트슬라이스 집합을 관리하게 할 수 있는 서비스 메시 구현과 같이
엔드포인트슬라이스에 대한 다양한 다른 유스케이스가 있다.
여러 엔티티가 서로 간섭하지 않고 엔드포인트슬라이스를
관리할 수 있도록 쿠버네티스는 엔드포인트슬라이스를 관리하는
엔티티를 나타내는 endpointslice.kubernetes.io/managed-by레이블을
정의한다.
엔드포인트 슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
endpointslice-controller.k8s.io 를 설정한다. 엔드포인트슬라이스를
관리하는 다른 엔티티도 이 레이블에 고유한 값을 설정해야 한다.
소유권
대부분의 유스케이스에서, 엔드포인트 슬라이스 오브젝트가 엔드포인트를
추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자
참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는
kubernetes.io/service-name 레이블로 표시된다.
엔드포인트슬라이스 미러링
경우에 따라, 애플리케이션이 사용자 지정 엔드포인트 리소스를 생성한다. 이러한
애플리케이션이 엔드포인트와 엔드포인트슬라이스 리소스에 동시에 쓸 필요가 없도록
클러스터의 컨트롤 플레인은 대부분의 엔드포인트 리소스를
해당 엔드포인트슬라이스에 미러링한다.
컨트롤 플레인은 다음을 제외하고 엔드포인트 리소스를 미러링한다.
엔드포인트 리소스에는 endpointslice.kubernetes.io/skip-mirror 레이블이
true 로 설정되어 있다.
엔드포인트 리소스에는 control-plane.alpha.kubernetes.io/leader
어노테이션이 있다.
해당 서비스 리소스가 존재하지 않는다.
해당 서비스 리소스에 nil이 아닌 셀렉터가 있다.
개별 엔드포인트 리소스는 여러 엔드포인트슬라이스로 변환될 수 있다.
엔드포인트 리소스에 여러 하위 집합이 있거나 여러 IP 제품군(IPv4 및 IPv6)이 있는
엔드포인트가 포함된 경우 변환이 일어난다. 하위 집합 당 최대 1000개의 주소가
엔드포인트슬라이스에 미러링된다.
엔드포인트슬라이스의 배포
각 엔드포인트슬라이스에는 리소스 내에 모든 엔드포인트가 적용되는
포트 집합이 있다. 서비스에 알려진 포트를 사용하는 경우 파드는
동일하게 알려진 포트에 대해 다른 대상 포트 번호로 끝날 수 있으며 다른
엔드포인트슬라이스가 필요하다. 이는 하위 집합이 엔드포인트와 그룹화하는
방식의 논리와 유사하다.
컨트롤 플레인은 엔드포인트슬라이스를 최대한 채우려고 노력하지만,
적극적으로 재조정하지는 않는다. 로직은 매우 직관적이다.
기존 엔드포인트슬라이스에 대해 반복적으로, 더 이상 필요하지 않는 엔드포인트를
제거하고 변경에 의해 일치하는 엔드포인트를 업데이트 한다.
첫 번째 단계에서 수정된 엔드포인트슬라이스를 반복해서
필요한 새 엔드포인트로 채운다.
추가할 새 엔드포인트가 여전히 남아있으면, 이전에 변경되지 않은
슬라이스에 엔드포인트를 맞추거나 새로운 것을 생성한다.
중요한 것은, 세 번째 단계는 엔드포인트슬라이스를 완벽하게 전부 배포하는 것보다
엔드포인트슬라이스 업데이트 제한을 우선시한다. 예를 들어, 추가할 새 엔드포인트가
10개이고 각각 5개의 공간을 사용할 수 있는 엔드포인트 공간이 있는 2개의
엔드포인트슬라이스가 있는 경우, 이 방법은 기존 엔드포인트슬라이스
2개를 채우는 대신에 새 엔드포인트슬라이스를 생성한다. 다른 말로, 단일
엔드포인트슬라이스를 생성하는 것이 여러 엔드포인트슬라이스를 업데이트하는 것 보다 더 선호된다.
각 노드에서 kube-proxy를 실행하고 엔드포인트슬라이스를 관찰하면,
엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기
때문에 상대적으로 비용이 많이 소요된다. 이 방법은 여러 엔드포인트슬라이스가
가득 차지 않은 결과가 발생할지라도, 모든 노드에 전송해야 하는
변경 횟수를 의도적으로 제한하기 위한 것이다.
실제로는, 이러한 이상적이지 않은 분배는 드물 것이다. 엔드포인트슬라이스
컨트롤러에서 처리하는 대부분의 변경 내용은 기존 엔드포인트슬라이스에
적합할 정도로 적고, 그렇지 않은 경우 새 엔드포인트슬라이스가
필요할 수 있다. 디플로이먼트의 롤링 업데이트도 모든 파드와 해당
교체되는 엔드포인트에 대해서 엔드포인트슬라이스를
자연스럽게 재포장한다.
중복 엔드포인트
엔드포인트슬라이스 변경의 특성으로 인해, 엔드포인트는 동시에 둘 이상의
엔드포인트슬라이스에 표시될 수 있다. 이는 다른 엔드포인트슬라이스 오브젝트에
대한 변경 사항이 다른 시간에서의 쿠버네티스 클라이언트 워치(watch)/캐시에
도착할 수 있기 때문에 자연스럽게 발생한다. 엔드포인트슬라이스를 사용하는 구현은
엔드포인트가 둘 이상의 슬라이스에 표시되도록 할 수 있어야 한다. 엔드포인트
중복 제거를 수행하는 방법에 대한 레퍼런스 구현은 kube-proxy 의
EndpointSliceCache 구현에서 찾을 수 있다.
kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
클러스터와 함께 자동으로 실행되지 않는다.
클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
프로젝트로서 쿠버네티스는 AWS, GCE와
nginx 인그레스 컨트롤러를 지원하고 유지한다.
추가 컨트롤러
주의:
이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.
하나의 클러스터 내에 여러 개의 인그레스 컨트롤러를 배포할 수 있다.
인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우
어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 ingress.class
어노테이션을 각각의 인그레스에 달아야 한다.
만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다.
이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만,
다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.
인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있다.
용어
이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다.
노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
클러스터 네트워크(Cluster network): 쿠버네티스 네트워킹 모델에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
서비스: 레이블 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 서비스. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
인그레스란?
인그레스는 클러스터 외부에서 클러스터 내부
서비스로 HTTP와 HTTPS 경로를 노출한다.
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.
graph LR;
client([클라이언트])-. 인그레스-매니지드 로드 밸런서 .->ingress[인그레스];
ingress-->|라우팅 규칙|service[서비스];
subgraph 클러스터
ingress;
service-->pod1[파드];
service-->pod2[파드];
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class ingress,service,pod1,pod2 k8s;
class client plain;
class cluster cluster;
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. 인그레스 컨트롤러는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 apiVersion, kind, 그리고 metadata 필드가 필요하다.
인그레스 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
설정 파일의 작성에 대한 일반적인 내용은 애플리케이션 배포하기, 컨테이너 구성하기, 리소스 관리하기를 참조한다.
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
그 예시는 재작성-타겟 어노테이션이다.
다른 인그레스 컨트롤러는 다른 어노테이션을 지원한다.
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
인그레스 사양
에는 로드 밸런서 또는 프록시 서버를 구성하는데 필요한 모든 정보가 있다. 가장 중요한 것은,
들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을
지시하는 규칙만 지원한다.
인그레스 규칙
각 HTTP 규칙에는 다음의 정보가 포함된다.
선택적 호스트. 이 예시에서는, 호스트가 지정되지 않기에 지정된 IP 주소를 통해 모든 인바운드
HTTP 트래픽에 규칙이 적용 된다. 만약 호스트가 제공되면(예,
foo.bar.com), 규칙이 해당 호스트에 적용된다.
경로 목록 (예, /testpath)에는 각각 service.name 과
service.port.name 또는 service.port.number 가 정의되어 있는 관련
백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로
보내기 전에 호스트와 경로가 모두 수신 요청의 내용과
일치해야 한다.
백엔드는 서비스 문서 또는 사용자 정의 리소스 백엔드에 설명된 바와 같이
서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한
HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다.
defaultBackend 는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스
컨트롤러에 구성되는 경우가 많다.
DefaultBackend
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. defaultBackend 는 일반적으로
인그레스 컨트롤러의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
기본 백엔드로 라우팅 된다.
리소스 백엔드
Resource 백엔드는 인그레스 오브젝트와 동일한 네임스페이스 내에 있는
다른 쿠버네티스 리소스에 대한 ObjectRef이다. Resource 는 서비스와
상호 배타적인 설정이며, 둘 다 지정하면 유효성 검사에 실패한다. Resource
백엔드의 일반적인 용도는 정적 자산이 있는 오브젝트 스토리지 백엔드로 데이터를
수신하는 것이다.
인그레스의 각 경로에는 해당 경로 유형이 있어야 한다. 명시적
pathType 을 포함하지 않는 경로는 유효성 검사에 실패한다. 지원되는
경로 유형은 세 가지이다.
ImplementationSpecific: 이 경로 유형의 일치 여부는 IngressClass에 따라
달라진다. 이를 구현할 때 별도 pathType 으로 처리하거나, Prefix 또는 Exact
경로 유형과 같이 동일하게 처리할 수 있다.
Exact: URL 경로의 대소문자를 엄격하게 일치시킨다.
Prefix: URL 경로의 접두사를 / 를 기준으로 분리한 값과 일치시킨다.
일치는 대소문자를 구분하고,
요소별로 경로 요소에 대해 수행한다.
모든 p 가 요청 경로의 요소별 접두사가 p 인 경우
요청은 p 경로에 일치한다.
참고: 경로의 마지막 요소가 요청 경로에 있는 마지막
요소의 하위 문자열인 경우에는 일치하지 않는다(예시: /foo/bar 와
/foo/bar/baz 와 일치하지만, /foo/barbaz 는 일치하지 않는다).
예제
종류
경로
요청 경로
일치 여부
Prefix
/
(모든 경로)
예
Exact
/foo
/foo
예
Exact
/foo
/bar
아니오
Exact
/foo
/foo/
아니오
Exact
/foo/
/foo
아니오
Prefix
/foo
/foo, /foo/
예
Prefix
/foo/
/foo, /foo/
예
Prefix
/aaa/bb
/aaa/bbb
아니오
Prefix
/aaa/bbb
/aaa/bbb
예
Prefix
/aaa/bbb/
/aaa/bbb
예, 마지막 슬래시 무시함
Prefix
/aaa/bbb
/aaa/bbb/
예, 마지막 슬래시 일치함
Prefix
/aaa/bbb
/aaa/bbb/ccc
예, 하위 경로 일치함
Prefix
/aaa/bbb
/aaa/bbbxyz
아니오, 문자열 접두사 일치하지 않음
Prefix
/, /aaa
/aaa/ccc
예, /aaa 접두사 일치함
Prefix
/, /aaa, /aaa/bbb
/aaa/bbb
예, /aaa/bbb 접두사 일치함
Prefix
/, /aaa, /aaa/bbb
/ccc
예, / 접두사 일치함
Prefix
/aaa
/ccc
아니오, 기본 백엔드 사용함
Mixed
/foo (Prefix), /foo (Exact)
/foo
예, Exact 선호함
다중 일치
경우에 따라 인그레스의 여러 경로가 요청과 일치할 수 있다.
이 경우 가장 긴 일치하는 경로가 우선하게 된다. 두 개의 경로가
여전히 동일하게 일치하는 경우 접두사(prefix) 경로 유형보다
정확한(exact) 경로 유형을 가진 경로가 사용 된다.
호스트네임 와일드카드
호스트는 정확한 일치(예: "foo.bar.com") 또는 와일드카드(예:
"* .foo.com")일 수 있다. 정확한 일치를 위해서는 HTTP host 헤더가
host 필드와 일치해야 한다. 와일드카드 일치를 위해서는 HTTP host 헤더가
와일드카드 규칙의 접미사와 동일해야 한다.
IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
추가 구성을 참조하는 데에 사용할 수 있다.
사용중단(Deprecated) 어노테이션
쿠버네티스 1.18에 IngressClass 리소스 및 ingressClassName 필드가 추가되기
전에 인그레스 클래스는 인그레스에서
kubernetes.io/ingress.class 어노테이션으로 지정되었다. 이 어노테이션은
공식적으로 정의된 것은 아니지만, 인그레스 컨트롤러에서 널리 지원되었었다.
인그레스의 최신 ingressClassName 필드는 해당 어노테이션을
대체하지만, 직접적으로 해당하는 것은 아니다. 어노테이션은 일반적으로
인그레스를 구현해야 하는 인그레스 컨트롤러의 이름을 참조하는 데 사용되었지만,
이 필드는 인그레스 컨트롤러의 이름을 포함하는 추가 인그레스 구성이
포함된 인그레스 클래스 리소스에 대한 참조이다.
기본 IngressClass
특정 IngressClass를 클러스터의 기본 값으로 표시할 수 있다. IngressClass
리소스에서 ingressclass.kubernetes.io/is-default-class 를 true 로
설정하면 ingressClassName 필드가 지정되지 않은
새 인그레스에게 기본 IngressClass가 할당된다.
주의: 클러스터의 기본값으로 표시된 IngressClass가 두 개 이상 있는 경우
어드미션 컨트롤러에서 ingressClassName 이 지정되지 않은
새 인그레스 오브젝트를 생성할 수 없다. 클러스터에서 최대 1개의 IngressClass가
기본값으로 표시하도록 해서 이 문제를 해결할 수 있다.
인그레스 유형들
단일 서비스로 지원되는 인그레스
단일 서비스를 노출할 수 있는 기존 쿠버네티스 개념이 있다
(대안을 본다). 인그레스에 규칙 없이 기본 백엔드 를 지정해서
이를 수행할 수 있다.
TLS 개인 키 및 인증서가 포함된 시크릿(Secret)을
지정해서 인그레스를 보호할 수 있다. 인그레스 리소스는
단일 TLS 포트인 443만 지원하고 인그레스 지점에서 TLS 종료를
가정한다(서비스 및 해당 파드에 대한 트래픽은 일반 텍스트임).
인그레스의 TLS 구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해
지정된 호스트이름에 따라 동일한 포트에서 멀티플렉싱
된다(인그레스 컨트롤러가 SNI를 지원하는 경우). TLS secret에는
tls.crt 와 tls.key 라는 이름의 키가 있어야 하고, 여기에는 TLS에 사용할 인증서와
개인 키가 있다. 예를 들어 다음과 같다.
인그레스에서 시크릿을 참조하면 인그레스 컨트롤러가 TLS를 사용하여
클라이언트에서 로드 밸런서로 채널을 보호하도록 지시한다. 생성한
TLS 시크릿이 https-example.foo.com 의 정규화 된 도메인 이름(FQDN)이라고
하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다.
참고: 가능한 모든 하위 도메인에 대해 인증서가 발급되어야 하기 때문에
TLS는 기본 규칙에서 작동하지 않는다. 따라서
tls 섹션의 hosts는 rules섹션의 host와 명시적으로 일치해야
한다.
참고: TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
차이가 있다. 사용자 환경에서의 TLS의 작동 방식을 이해하려면
nginx,
GCE 또는 기타
플랫폼의 특정 인그레스 컨트롤러에 대한 설명서를 참조한다.
로드 밸런싱
인그레스 컨트롤러는 로드 밸런싱 알고리즘, 백엔드 가중치 구성표 등
모든 인그레스에 적용되는 일부 로드 밸런싱
정책 설정으로 부트스트랩된다. 보다 진보된 로드 밸런싱 개념
(예: 지속적인 세션, 동적 가중치)은 아직 인그레스를 통해
노출되지 않는다. 대신 서비스에 사용되는 로드 밸런서를 통해 이러한 기능을
얻을 수 있다.
또한, 헬스 체크를 인그레스를 통해 직접 노출되지 않더라도, 쿠버네티스에는
준비 상태 프로브와
같은 동일한 최종 결과를 얻을 수 있는 병렬 개념이
있다는 점도 주목할 가치가 있다. 컨트롤러 별
설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다(예:
nginx, 또는
GCE).
인그레스 업데이트
기존 인그레스를 업데이트해서 새 호스트를 추가하려면, 리소스를 편집해서 호스트를 업데이트 할 수 있다.
kubectl describe ingress test
Name: test
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo service1:80 (10.8.0.90:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 35s loadbalancer-controller default/test
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 파드가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다.
파드가 통신할 수 있는 엔티티는 다음 3개의 식별자 조합을 통해 식별된다.
허용되는 다른 파드(예외: 파드는 자신에 대한 접근을 차단할 수 없음)
허용되는 네임스페이스
IP 블록(예외: 파드 또는 노드의 IP 주소와 관계없이 파드가 실행 중인 노드와의 트래픽은 항상 허용됨)
pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, 셀렉터를 사용하여 셀렉터와 일치하는 파드와 주고받는 트래픽을 지정한다.
한편, IP 기반의 네트워크폴리시가 생성되면, IP 블록(CIDR 범위)을 기반으로 정책을 정의한다.
전제 조건
네트워크 정책은 네트워크 플러그인으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다.
격리 및 격리되지 않은 파드
기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다.
파드는 파드를 선택한 네트워크폴리시에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 네트워크폴리시가 있으면 해당 파드는 네트워크폴리시에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 네트워크폴리시에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.)
네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
두 파드간 네트워크 흐름을 허용하기 위해서는, 소스 파드의 이그레스 정책과 목적지 파드의 인그레스 정책 모두가 해당 트래픽을 허용해야 한다. 만약 소스의 이그레스 정책이나 목적지의 인그레스 정책 중 한쪽이라도 트래픽을 거절하게 되어 있다면, 해당 트래픽은 거절될 것이다.
참고: 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
필수 필드들: 다른 모든 쿠버네티스 설정과 마찬가지로 네트워크폴리시 에는
apiVersion, kind, 그리고 metadata 필드가 필요하다. 구성 파일
작업에 대한 일반적인 정보는
컨피그 맵을 사용해서 컨테이너 구성하기,
그리고 오브젝트 관리 를 본다.
spec: 네트워크폴리시 사양에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
podSelector: 각 네트워크폴리시에는 정책이 적용되는 파드 그룹을 선택하는 podSelector 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 podSelector 는 네임스페이스의 모든 파드를 선택한다.
policyTypes: 각 네트워크폴리시에는 Ingress, Egress 또는 두 가지 모두를 포함할 수 있는 policyTypes 목록이 포함된다. policyTypes 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 policyTypes 가 지정되어 있지 않으면 기본적으로 Ingress 가 항상 설정되고, 네트워크폴리시에 Egress 가 있으면 이그레스 규칙이 설정된다.
ingress: 각 네트워크폴리시에는 화이트리스트 ingress 규칙 목록이 포함될 수 있다. 각 규칙은 from 과 ports 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 ipBlock 을 통해 지정되고, 두 번째는 namespaceSelector 를 통해 그리고 세 번째는 podSelector 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
egress: 각 네트워크폴리시에는 화이트리스트 egress 규칙이 포함될 수 있다. 각 규칙은 to 와 ports 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 10.0.0.0/24 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
따라서 예시의 네트워크폴리시는 다음과 같이 동작한다.
인그레스 및 이그레스 트래픽에 대해 "default" 네임스페이스에서 "role=db"인 파드를 격리한다(아직 격리되지 않은 경우).
(인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6397로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다.
"role=frontend" 레이블이 있는 "default" 네임스페이스의 모든 파드
네임스페이스와 "project=myproject" 를 레이블로 가지는 모든 파드
172.17.0.0–172.17.0.255 와 172.17.2.0–172.17.255.255 의 범위를 가지는 IP 주소(예: 172.17.0.0/16 전체에서 172.17.1.0/24 를 제외)
(이그레스 규칙)은 "role=db" 레이블이 있는 "default" 네임스페이스의 모든 파드에서 TCP 포트 5978의 CIDR 10.0.0.0/24 로의 연결을 허용한다.
from 배열에 두 개의 요소가 포함되어 있으며, 로컬 네임스페이스에 레이블을 role=client 로 가지는 파드 또는 네임스페이스에 레이블을 user=alice 로 가지는 파드의 연결을 허용한다.
의심스러운 경우, kubectl describe 를 사용해서 쿠버네티스가 정책을 어떻게 해석하는지 확인해본다.
ipBlock: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다.
클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을
필요로 한다. 이러한 상황이 발생하는 경우, 네트워크폴리시의 처리 전 또는 후에
발생한 것인지 정의되지 않으며, 네트워크 플러그인, 클라우드 공급자,
서비스 구현 등의 조합에 따라 동작이 다를 수 있다.
인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을
필터링할 수 있는 반면에 다른 경우에는 네트워크폴리시가 작동하는
"소스 IP"는 LoadBalancer 또는 파드가 속한 노드 등의 IP일 수 있다.
이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 서비스 IP로의 연결은
ipBlock 기반의 정책의 적용을 받거나 받지 않을 수 있다는 것을 의미한다.
기본 정책
기본적으로 네임스페이스 정책이 없으면 해당 네임스페이스의 파드에 대한 모든 인그레스와 이그레스 트래픽이 허용된다. 다음 예시에서는 해당 네임스페이스의 기본 동작을
변경할 수 있다.
기본적으로 모든 인그레스 트래픽 거부
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.
SCTP 지원
FEATURE STATE:Kubernetes v1.19 [beta]
베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 --feature-gates=SCTPSupport=false,… 를 사용해서 SCTPSupport기능 게이트를 비활성화해야 한다.
참고: SCTP 프로토콜 네트워크폴리시를 지원하는 CNI 플러그인을 사용하고 있어야 한다.
네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다.
내부 클러스터 트래픽이 공통 게이트웨이를 통과하도록 강제한다(서비스 메시나 기타 프록시와 함께 제공하는 것이 가장 좋을 수 있음).
TLS와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용).
노드별 정책(이에 대해 CIDR 표기법을 사용할 수 있지만, 특히 쿠버네티스 ID로 노드를 대상으로 지정할 수 없음).
이름으로 네임스페이스나 서비스를 타겟팅한다(그러나, 레이블로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임).
타사 공급사가 이행한 "정책 요청"의 생성 또는 관리.
모든 네임스페이스나 파드에 적용되는 기본 정책(이를 수행할 수 있는 타사 공급사의 쿠버네티스 배포본 및 프로젝트가 있음).
고급 정책 쿼리 및 도달 가능성 도구.
단일 정책 선언에서 포트 범위를 대상으로 하는 기능.
네트워크 보안 이벤트를 기록하는 기능(예: 차단되거나 수락된 연결).
명시적으로 정책을 거부하는 기능(현재 네트워크폴리시 모델은 기본적으로 거부하며, 허용 규칙을 추가하는 기능만 있음).
루프백 또는 들어오는 호스트 트래픽을 방지하는 기능(파드는 현재 로컬 호스트 접근을 차단할 수 없으며, 상주 노드의 접근을 차단할 수 있는 기능도 없음).
기본적으로, hosts 파일은 localhost와 자기 자신의 호스트네임과 같은 IPv4와 IPv6
상용구들만 포함하고 있다.
hostAliases를 사용하여 추가 항목들 추가하기
기본 상용구 이외에, 추가 항목들을 hosts 파일에
추가할 수 있다.
예를 들어, foo.local, bar.local이 127.0.0.1로,
foo.remote, bar.remote가 10.1.2.3로 해석될 수 있도록, .spec.hostAliases 항목에서 정의하여 파드에
HostAliases를 추가하면 가능하다.
--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6 IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
kubelet:
--feature-gates="IPv6DualStack=true"
kube-proxy:
--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>
--feature-gates="IPv6DualStack=true"
참고:
IPv4 CIDR의 예: 10.244.0.0/16 (자신의 주소 범위를 제공하더라도)
IPv6 CIDR의 예: fdXY:IJKL:MNOP:15::/64 (이 형식으로 표시되지만, 유효한 주소는 아니다 - RFC 4193을 본다.)
서비스
클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 서비스를 만들 수 있다.
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (--service-cluster-ip-range 플래그를 통해 kube-apiserver에 구성)
서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 .spec.ipFamilyPolicy 필드를
다음 값 중 하나로 설정한다.
SingleStack: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
PreferDualStack:
클러스터에 이중 스택이 활성화된 경우에만 사용된다. 서비스에 대해 IPv4 및 IPv6 클러스터 IP를 할당한다.
클러스터에 이중 스택이 활성화되지 않은 경우, 이 설정은 SingleStack과 동일한 동작을 따른다.
RequireDualStack: IPv4 및 IPv6 주소 범위 모두에서 서비스 .spec.ClusterIPs를 할당한다.
.spec.ipFamilies 배열의 첫 번째 요소의 주소 계열을 기반으로 .spec.ClusterIPs 목록에서 .spec.ClusterIP를 선택한다.
클러스터에는 이중 스택 네트워킹이 구성되어 있어야 한다.
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 .spec.ipFamilies를 설정하여 주소 군을 선택할 수 있다.
참고:.spec.ipFamilies 필드는 이미 존재하는 서비스에 .spec.ClusterIP를 재할당할 수 없기 때문에 변경할 수 없다. .spec.ipFamilies를 변경하려면 서비스를 삭제하고 다시 생성한다.
.spec.ipFamilies를 다음 배열 값 중 하나로 설정할 수 있다.
["IPv4"]
["IPv6"]
["IPv4","IPv6"] (이중 스택)
["IPv6","IPv4"] (이중 스택)
나열한 첫 번째 군은 레거시.spec.ClusterIP 필드에 사용된다.
이중 스택 서비스 구성 시나리오
이 예제는 다양한 이중 스택 서비스 구성 시나리오의 동작을 보여준다.
새로운 서비스에 대한 이중 스택 옵션
이 서비스 사양은 .spec.ipFamilyPolicy를 명시적으로 정의하지 않는다. 이 서비스를 만들 때 쿠버네티스는 처음 구성된 service-cluster-ip-range에서 서비스에 대한 클러스터 IP를 할당하고 .spec.ipFamilyPolicy를 SingleStack으로 설정한다. (셀렉터가 없는 서비스 및 헤드리스 서비스와 같은 방식으로 동작한다.)
이 서비스 사양은 .spec.ipFamilyPolicy에 PreferDualStack을 명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는 서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의 .spec을 업데이트하여 IP 주소 할당을 기록한다. 필드 .spec.ClusterIPs는 기본 필드이며 할당된 IP 주소를 모두 포함한다. .spec.ClusterIP는 값이 .spec.ClusterIPs에서 계산된 보조 필드이다.
.spec.ClusterIP 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP 범위와 동일한 주소 계열의 IP 주소를 기록한다.
단일 스택 클러스터에서 .spec.ClusterIPs 및 .spec.ClusterIP 필드는 모두 하나의 주소만 나열한다.
이중 스택이 활성화된 클러스터에서 .spec.ipFamilyPolicy에 RequireDualStack을 지정하면 PreferDualStack과 동일하게 작동한다.
이 서비스 사양은 .spec.ipFamilies에 IPv6과 IPv4를 명시적으로 정의하고 .spec.ipFamilyPolicy에 PreferDualStack을 정의한다. 쿠버네티스가 .spec.ClusterIPs에 IPv6 및 IPv4 주소를 할당할 때 .spec.ClusterIP는 .spec.ClusterIPs 배열의 첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다.
이 예제는 서비스가 이미있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다.
클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (IPv4 또는 IPv6)는 컨트롤 플레인이 .spec.ipFamilyPolicy를 SingleStack으로 지정하고 .spec.ipFamilies를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 .spec.ClusterIPs에 저장한다.
클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 헤드리스 서비스는 .spec.ClusterIP가 None이라도 컨트롤 플레인이 .spec.ipFamilyPolicy을 SingleStack으로 지정하고 .spec.ipFamilies는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 --service-cluster-ip-range 플래그를 통해 구성)의 주소 계열으로 지정한다.
서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 .spec.ipFamilyPolicy를 SingleStack에서 PreferDualStack 또는 RequireDualStack으로 변경한다. 이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의 것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖게된다.
.spec.ipFamilyPolicy를 SingleStack에서 PreferDualStack으로 업데이트하는 서비스 사양을 편집한다.
이전:
spec:ipFamilyPolicy:SingleStack
이후:
spec:ipFamilyPolicy:PreferDualStack
서비스를 이중 스택에서 단일 스택으로 변경하려면 .spec.ipFamilyPolicy를 PreferDualStack에서 또는 RequireDualStack을 SingleStack으로 변경한다. 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 .spec.ClusterIPs 배열의 첫 번째 요소 만 유지하고 .spec.ClusterIP를 해당 IP 주소로 설정하고 .spec.ipFamilies를 .spec.ClusterIPs의 주소 계열로 설정한다.
셀렉터가 없는 헤드리스 서비스
셀렉터가 없는 서비스 및 .spec.ipFamilyPolicy가 명시적으로 설정되지 않은 경우 .spec.ipFamilyPolicy 필드의 기본값은 RequireDualStack 이다.
로드밸런서 서비스 유형
서비스에 이중 스택 로드밸런서를 프로비저닝하려면
.spec.type 필드를 LoadBalancer로 설정
.spec.ipFamilyPolicy 필드를 PreferDualStack 또는 RequireDualStack으로 설정
참고: 이중 스택 LoadBalancer 유형 서비스를 사용하려면 클라우드 공급자가 IPv4 및 IPv6로드 밸런서를 지원해야 한다.
이그레스(Egress) 트래픽
비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상 (예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는 IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다. ip-masq-agent 프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다.
컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때
애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 한 가지 문제는
컨테이너가 크래시될 때 파일이 손실된다는 것이다. kubelet은 컨테이너를 다시 시작하지만
초기화된 상태이다. 두 번째 문제는 Pod에서 같이 실행되는 컨테이너간에
파일을 공유할 때 발생한다.
쿠버네티스 볼륨 추상화는
이러한 문제를 모두 해결한다.
도커는 다소 느슨하고, 덜 관리되지만
볼륨이라는
개념을 가지고 있다. 도커 볼륨은 디스크에 있는 디렉터리이거나
다른 컨테이너에 있다. 도커는 볼륨
드라이버를 제공하지만, 기능이 다소 제한된다.
쿠버네티스는 다양한 유형의 볼륨을 지원한다. 파드는
여러 볼륨 유형을 동시에 사용할 수 있다.
임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은
파드의 수명을 넘어 존재한다. 결과적으로, 볼륨은 파드 내에서
실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작해도 데이터가 보존된다. 파드가
더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.
기본적으로 볼륨은 디렉터리이며, 일부 데이터가 있을 수 있으며, 파드
내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는
매체와 내용은 사용된 특정 볼륨의 유형에 따라
결정된다.
볼륨을 사용하려면, .spec.volumes 에서 파드에 제공할 볼륨을 지정하고
.spec.containers[*].volumeMounts 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다.
컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템
뷰를 본다. 도커 이미지는
파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에
마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를
가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로
지정해야 한다.
볼륨 유형들
쿠버네티스는 여러 유형의 볼륨을 지원한다.
awsElasticBlockStore
awsElasticBlockStore 볼륨은 아마존 웹 서비스 (AWS)
EBS 볼륨을 파드에 마운트 한다. 파드를
제거할 때 지워지는 emptyDir 와는 다르게 EBS 볼륨의
내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 EBS 볼륨에
데이터를 미리 채울 수 있으며, 파드 간에 데이터를 "전달(handed off)"할 수 있다.
참고: 이를 사용하려면 먼저 aws ec2 create-volume 또는 AWS API를 사용해서 EBS 볼륨을 생성해야 한다.
클러스터를 띄운 영역과 생성하는 영역이 일치하는지 확인한다. 크기와 EBS 볼륨 유형이
사용에 적합한지 확인한다.
AWS EBS 구성 예시
apiVersion:v1kind:Podmetadata:name:test-ebsspec:containers:- image:k8s.gcr.io/test-webservername:test-containervolumeMounts:- mountPath:/test-ebsname:test-volumevolumes:- name:test-volume# 이 AWS EBS 볼륨은 이미 존재해야 한다.awsElasticBlockStore:volumeID:"<volume-id>"fsType:ext4
EBS 볼륨이 파티션된 경우, 선택적 필드인 partition: "<partition number>" 를 제공하여 마운트할 파티션을 지정할 수 있다.
AWS EBS CSI 마이그레이션
FEATURE STATE:Kubernetes v1.17 [beta]
awsElasticBlockStore 의 CSIMigration 기능이 활성화된 경우, 기존 인-트리 플러그인의
모든 플러그인 작업을 ebs.csi.aws.com 컨테이너 스토리지 인터페이스(CSI)
드라이버로 리디렉션한다. 이 기능을 사용하려면, 클러스터에 AWS EBS CSI
드라이버를
설치하고 CSIMigration 과 CSIMigrationAWS
베타 기능을 활성화해야 한다.
AWS EBS CSI 마이그레이션 완료
FEATURE STATE:Kubernetes v1.17 [alpha]
컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 awsElasticBlockStore 스토리지
플러그인을 끄려면, CSIMigrationAWSComplete 플래그를 true 로 설정한다. 이 기능은 모든 워커 노드에서 ebs.csi.aws.com 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다.
azureDisk
azureDisk 볼륨 유형은 Microsoft Azure 데이터 디스크를 파드에 마운트한다.
azureDisk 의 CSIMigration 기능이 활성화된 경우, 기존 트리 내 플러그인에서
disk.csi.azure.com 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 Azure 디스크 CSI
드라이버
를 설치하고 CSIMigration 과 CSIMigrationAzureDisk
기능을 활성화해야 한다.
azureFile
azureFile 볼륨 유형은 Microsoft Azure 파일 볼륨(SMB 2.1과 3.0)을 파드에
마운트한다.
azureFile 의 CSIMigration 기능이 활성화된 경우, 기존 트리 내 플러그인에서
file.csi.azure.com 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 Azure 파일 CSI
드라이버
를 설치하고 CSIMigration 과 CSIMigrationAzureFile
알파 기능을 활성화해야 한다.
cephfs
cephfs 볼륨은 기존 CephFS 볼륨을
파드에 마운트 할 수 있다. 파드를 제거할 때 지워지는 emptyDir
와는 다르게 cephfs 볼륨의 내용은 유지되고, 볼륨은 그저 마운트
해제만 된다. 이 의미는 cephfs 볼륨에 데이터를 미리 채울 수 있으며,
해당 데이터는 파드 간에 공유될 수 있다. cephfs 볼륨은 여러 작성자가
동시에 마운트할 수 있다.
참고: CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다.
apiVersion:v1kind:Podmetadata:name:test-cinderspec:containers:- image:k8s.gcr.io/test-webservername:test-cinder-containervolumeMounts:- mountPath:/test-cindername:test-volumevolumes:- name:test-volume# 이 오픈스택 볼륨은 이미 존재해야 한다.cinder:volumeID:"<volume id>"fsType:ext4
오픈스택 CSI 마이그레이션
FEATURE STATE:Kubernetes v1.18 [beta]
Cinder의 CSIMigration 기능이 활성화된 경우, 기존 트리 내 플러그인에서
cinder.csi.openstack.org 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 오픈스택 Cinder CSI
드라이버를
설치하고 CSIMigration 과 CSIMigrationOpenStack
베타 기능을 활성화해야 한다.
컨피그맵(configMap)
컨피그맵은
구성 데이터를 파드에 주입하는 방법을 제공한다.
컨피그맵에 저장된 데이터는 configMap 유형의 볼륨에서 참조되고
그런 다음에 파드에서 실행되는 컨테이너화된 애플리케이션이 소비한다.
컨피그맵을 참조할 때, 볼륨에 컨피그맵의 이름을
제공한다. 컨피그맵의 특정 항목에 사용할 경로를
사용자 정의할 수 있다. 다음 구성은 log-config 컨피그맵을
configmap-pod 라 부르는 파드에 마운트하는 방법을 보여준다.
emptyDir 볼륨은 파드가 노드에 할당될 때 처음 생성되며,
해당 노드에서 파드가 실행되는 동안에만 존재한다. 이름에서 알 수 있듯이
emptyDir 볼륨은 처음에는 비어있다. 파드 내 모든 컨테이너는 emptyDir 볼륨에서 동일한
파일을 읽고 쓸 수 있지만, 해당 볼륨은 각각의 컨테이너에서 동일하거나
다른 경로에 마운트될 수 있다. 어떤 이유로든 노드에서 파드가 제거되면
emptyDir 의 데이터가 영구적으로 삭제된다.
참고: 컨테이너가 크래시되는 것은 노드에서 파드를 제거하지 않는다. emptyDir 볼륨의 데이터는
컨테이너 크래시로부터 안전하다.
emptyDir 의 일부 용도는 다음과 같다.
디스크 기반의 병합 종류와 같은 스크레치 공간
충돌로부터 복구하기위해 긴 계산을 검사점으로 지정
웹 서버 컨테이너가 데이터를 처리하는 동안 컨텐츠 매니저
컨테이너가 가져오는 파일을 보관
환경에 따라, emptyDir 볼륨은 디스크, SSD 또는 네트워크 스토리지와
같이 노드를 지원하는 모든 매체에 저장된다. 그러나, emptyDir.medium 필드를
"Memory"로 설정하면, 쿠버네티스에 tmpfs(RAM 기반 파일시스템)를 마운트하도록 할 수 있다.
tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs가 지워지고,
작성하는 모든 파일이 컨테이너 메모리
제한에 포함된다.
참고:SizeMemoryBackedVolumes기능 게이트가 활성화된 경우,
메모리 기반 볼륨의 크기를 지정할 수 있다. 크기를 지정하지 않으면, 메모리
기반 볼륨의 크기는 리눅스 호스트 메모리의 50%로 조정된다.
fc 볼륨 유형은 기존 파이버 채널 블록 스토리지 볼륨을
파드에 마운트할 수 있게 한다. 볼륨 구성에서 targetWWNs 파라미터를 사용하여
단일 또는 다중 대상 월드 와이드 이름(WWN)을 지정할 수 있다. 만약 여러 WWN이 지정된 경우,
targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다.
참고: 이러한 LUN (볼륨)을 할당하고 대상 WWN에 마스킹하도록 FC SAN Zoning을 구성해야만
쿠버네티스 호스트가 해당 LUN에 접근할 수 있다.
Flocker는 오픈소스이고, 클러스터
컨테이너 데이터 볼륨 매니저이다. Flocker는 다양한
스토리지 백엔드가 지원하는 데이터 볼륨 관리와 오케스트레이션을 제공한다.
flocker 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약
Flocker내에 데이터셋이 없는 경우, 먼저 Flocker
CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면
Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에
따라 파드 간에 데이터를 공유할 수 있다는 의미이다.
gcePersistentDisk 볼륨은 구글 컴퓨트 엔진(GCE)
영구 디스크(PD)를 파드에 마운트한다.
파드를 제거할 때 지워지는 emptyDir 와는 다르게, PD의 내용은 유지되고,
볼륨은 마운트 해제만 된다. 이는 PD에 데이터를
미리 채울 수 있으며, 파드 간에 데이터를 공유할 수 있다는 것을 의미한다.
참고:gcePersistentDisk 를 사용하려면 먼저 PD를 gcloud, GCE API 또는 UI를 사용해서 생성해야 한다.
gcePersistentDisk 를 사용할 때 몇 가지 제한이 있다.
파드가 실행 중인 노드는 GCE VM이어야 함
이러한 VM은 영구 디스크와 동일한 GCE 프로젝트와 영역에 있어야 함
GCE 영구 디스크의 한 가지 기능은 영구 디스크에 대한 동시 읽기 전용 접근이다.
gcePersistentDisk 볼륨을 사용하면 여러 사용자가 영구 디스크를 읽기 전용으로
동시에 마운트할 수 있다. 즉, PD를 데이터 세트로 미리 채운 다음
필요한 만큼 많은 파드에서 병렬로 제공할 수 있다. 불행히도,
PD는 읽기-쓰기 모드에서 단일 사용자만 마운트할 수 있다. 동시
쓰기는 허용되지 않는다.
PD가 읽기 전용이거나 레플리카의 수가 0 또는 1이 아니라면 레플리카셋(ReplicaSet)으로 제어되는
파드가 있는 GCE 영구 디스크를 사용할 수 없다.
apiVersion:v1kind:Podmetadata:name:test-pdspec:containers:- image:k8s.gcr.io/test-webservername:test-containervolumeMounts:- mountPath:/test-pdname:test-volumevolumes:- name:test-volume# 이 GCE PD는 이미 존재해야 한다.gcePersistentDisk:pdName:my-data-diskfsType:ext4
리전 영구 디스크
리전 영구 디스크
기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 영구 디스크를
생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨(PersistentVolume)으로
프로비저닝해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다.
리전 PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기
GCE PD용 스토리지클래스를
사용해서 동적 프로비저닝이 가능하다.
퍼시스턴트볼륨을 생성하기 전에 영구 디스크를 생성해야만 한다.
GCE PD의 CSIMigration 기능이 활성화된 경우 기존 인-트리 플러그인에서
pd.csi.storage.gke.io 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 리디렉션한다. 이 기능을 사용하려면, 클러스터에 GCE PD CSI
드라이버
를 설치하고 CSIMigration 과 CSIMigrationGCE
베타 기능을 활성화해야 한다.
gitRepo (사용 중단됨)
경고:gitRepo 볼륨 유형은 사용 중단되었다. git repo가 있는 컨테이너를 프로비전 하려면 초기화 컨테이너(InitContainer)에 EmptyDir을 마운트하고, 여기에 git을 사용해서 repo를 복제하고, EmptyDir을 파드 컨테이너에 마운트 한다.
gitRepo 볼륨은 볼륨 플러그인의 예시이다. 이 플러그인은
빈 디렉터리를 마운트하고 파드가 사용할 수 있도록 이 디렉터리에 git 리포지터리를
복제한다.
glusterfs 볼륨을 사용하면 Glusterfs (오픈
소스 네트워크 파일시스템) 볼륨을 파드에 마운트할 수 있다. 파드를
제거할 때 지워지는 emptyDir 와는 다르게 glusterfs
볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는
glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데이터를
공유할 수 있다. GlusterFS는 여러 작성자가 동시에
마운트할 수 있다.
hostPath 볼륨은 호스트 노드의 파일시스템에 있는 파일이나 디렉터리를
파드에 마운트 한다. 이것은 대부분의 파드들이 필요한 것은 아니지만, 일부
애플리케이션에 강력한 탈출구를 제공한다.
예를 들어, hostPath 의 일부 용도는 다음과 같다.
도커 내부에 접근할 필요가 있는 실행중인 컨테이너. /var/lib/docker 를
hostPath 로 이용함
컨테이너에서 cAdvisor의 실행. /sys 를 hostPath 로 이용함
파드는 주어진 hostPath 를 파드가 실행되기 이전에 있어야 하거나,
생성해야 하는지 그리고 존재해야 하는 대상을 지정할 수 있도록 허용함
필요한 path 속성 외에도, hostPath 볼륨에 대한 type 을 마음대로 지정할 수 있다.
필드가 type 에 지원되는 값은 다음과 같다.
값
행동
빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPath 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다.
DirectoryOrCreate
만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0755로 설정한 빈 디렉터리를 생성한다.
Directory
주어진 경로에 디렉터리가 있어야 함
FileOrCreate
만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 디렉터리를 생성한다.
File
주어진 경로에 파일이 있어야 함
Socket
주어진 경로에 UNIX 소캣이 있어야 함
CharDevice
주어진 경로에 문자 디바이스가 있어야 함
BlockDevice
주어진 경로에 블록 디바이스가 있어야 함
다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다.
동일한 구성(파드템플릿으로 생성한 것과 같은)을
가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다.
기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다.
프로세스를 특권을 가진(privileged) 컨테이너에서
루트로 실행하거나
hostPath 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다.
hostPath 구성 예시
apiVersion:v1kind:Podmetadata:name:test-pdspec:containers:- image:k8s.gcr.io/test-webservername:test-containervolumeMounts:- mountPath:/test-pdname:test-volumevolumes:- name:test-volumehostPath:# 호스트의 디렉터리 위치path:/data# 이 필드는 선택 사항이다type:Directory
주의:FileOrCreate 모드는 파일의 상위 디렉터리를 생성하지 않는다. 마운트된 파일의 상위 디렉터리가
없으면 파드가 시작되지 않는다. 이 모드가 작동하는지 확인하려면,
FileOrCreate 구성에 표시된대로
디렉터리와 파일을 별도로 마운트할 수 있다.
hostPath FileOrCreate 구성 예시
apiVersion:v1kind:Podmetadata:name:test-webserverspec:containers:- name:test-webserverimage:k8s.gcr.io/test-webserver:latestvolumeMounts:- mountPath:/var/local/aaaname:mydir- mountPath:/var/local/aaa/1.txtname:myfilevolumes:- name:mydirhostPath:# 파일 디렉터리가 생성되었는지 확인한다.path:/var/local/aaatype:DirectoryOrCreate- name:myfilehostPath:path:/var/local/aaa/1.txttype:FileOrCreate
iscsi
iscsi 볼륨을 사용하면 기존 iSCSI (SCSI over IP) 볼륨을 파드에 마운트
할수 있다. 파드를 제거할 때 지워지는 emptyDir 와는
다르게 iscsi 볼륨의 내용은 유지되고, 볼륨은 그저 마운트
해제만 된다. 이 의미는 iscsi 볼륨에 데이터를 미리 채울 수 있으며,
파드간에 데이터를 공유할 수 있다는 것이다.
참고: 사용하려면 먼저 iSCSI 서버를 실행하고 볼륨을 생성해야 한다.
iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수
있다는 것이다. 즉, 데이터셋으로 사전에 볼륨을 채운다음,
필요한 만큼 많은 파드에서 병렬로 제공할 수 있다. 불행하게도,
iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있다.
동시 쓰기는 허용되지 않는다.
local 볼륨은 디스크, 파티션 또는 디렉터리 같은 마운트된 로컬 스토리지
장치를 나타낸다.
로컬 볼륨은 정적으로 생성된 퍼시스턴트볼륨으로만 사용할 수 있다. 동적으로
프로비저닝된 것은 지원되지 않는다.
hostPath 볼륨에 비해 local 볼륨은 수동으로 파드를 노드에 예약하지 않고도
내구성과 휴대성을 갖춘 방식으로 사용된다. 시스템은
퍼시스턴트볼륨의 노드 어피니티를 확인하여 볼륨의 노드 제약 조건을 인식한다.
그러나 local 볼륨은 여전히 기본 노드의 가용성을 따르며
모든 애플리케이션에 적합하지는 않는다. 만약 노드가 비정상 상태가
되면 local 볼륨도 접근할 수 없게 되고, 파드를 실행할 수
없게 된다. local 볼륨을 사용하는 애플리케이션은 기본 디스크의
내구 특성에 따라 이러한 감소되는 가용성과 데이터
손실 가능성도 허용할 수 있어야 한다.
다음의 예시는 local 볼륨과 nodeAffinity 를 사용하는 퍼시스턴트볼륨을
보여준다.
local 볼륨을 사용하는 경우 퍼시스턴트볼륨 nodeAffinity 를 설정해야 합니다.
쿠버네티스 스케줄러는 퍼시스턴트볼륨 nodeAffinity 를 사용하여
파드를 올바른 노드로 스케줄한다.
퍼시스턴트볼륨의 volumeMode 을 "Block" (기본값인 "Filesystem"을
대신해서)으로 설정하면 로컬 볼륨을 원시 블록 장치로 노출할 수 있다.
로컬 볼륨을 사용할 때는 volumeBindingMode 가 WaitForFirstConsumer 로 설정된
스토리지클래스(StorageClass)를 생성하는 것을 권장한다. 자세한 내용은
local 스토리지클래스(StorageClas) 예제를 참고한다.
볼륨 바인딩을 지연시키는 것은 퍼시스턴트볼륨클래임 바인딩 결정도
노드 리소스 요구사항, 노드 셀렉터, 파드 어피니티 그리고 파드 안티 어피니티와
같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다.
로컬 볼륨 라이프사이클의 향상된 관리를 위해 외부 정적
프로비저너를 별도로 실행할 수 있다. 이 프로비저너는 아직 동적
프로비저닝을 지원하지 않는 것을 참고한다. 외부 로컬 프로비저너를 실행하는 방법에 대한
예시는 로컬 볼륨 프로비저너 사용자
가이드를 본다.
참고: 로컬 정적 프로비저너를 사용해서 볼륨 라이프사이클을 관리하지 않는
경우 로컬 퍼시스턴트볼륨을 수동으로 정리하고 삭제하는 것이
필요하다.
nfs
nfs 볼륨을 사용하면 기존 NFS (네트워크 파일 시스템) 볼륨을 파드에 마운트
할수 있다. 파드를 제거할 때 지워지는 emptyDir 와는
다르게 nfs 볼륨의 내용은 유지되고, 볼륨은 그저 마운트
해제만 된다. 이 의미는 NFS 볼륨에 데이터를 미리 채울 수 있으며,
파드 간에 데이터를 공유할 수 있다는 뜻이다. NFS는 여러 작성자가
동시에 마운트할 수 있다.
persistentVolumeClaim 볼륨은
퍼시스턴트볼륨을 파드에 마운트하는데 사용한다. 퍼시스턴트볼륨클레임은
사용자가 특정 클라우드 환경의 세부 내용을 몰라도 내구성이있는 스토리지 (GCE 퍼시스턴트디스크 또는
iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다.
portworxVolume 은 쿠버네티스와 하이퍼컨버지드(hyperconverged)를 실행하는 탄력적인 블록 스토리지
계층이다. Portworx는 서버의
스토리지를 핑거프린팅하고(fingerprints), 기능에 기반하여 계층화하고, 그리고 여러 서버에 걸쳐 용량을 집계한다.
Portworx는 가상 머신 내 게스트 또는 베어 메탈 리눅스 노드 위에서 실행된다.
portworxVolume 은 쿠버네티스를 통해 동적으로 생성되거나
사전에 프로비전할 수 있으며 쿠버네티스 파드 내에서 참조할 수 있다.
다음은 사전에 프로비저닝된 Portworx 볼륨을 참조하는 파드의 예시이다.
apiVersion:v1kind:Podmetadata:name:test-portworx-volume-podspec:containers:- image:k8s.gcr.io/test-webservername:test-containervolumeMounts:- mountPath:/mntname:pxvolvolumes:- name:pxvol# 이 Portworx 볼륨은 이미 존재해야 한다.portworxVolume:volumeID:"pxvol"fsType:"<fs-type>"
참고: 파드에서 사용하기 이전에 먼저 이름이 pxvol 인 PortworxVolume이
있는지 확인한다.
예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이
있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데
사용할 수 있다. audience 필드는 토큰에 의도하는 대상을
포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며,
그렇지 않으면 토큰을 거부해야 한다. 이 필드는
선택 사항이며 기본값은 API 서버의 식별자이다.
expirationSeconds 는 서비스 어카운트 토큰의 예상 유효
기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는
API 서버에 대해 --service-account-max-token-expiration 옵션을 지정해서
최대 값을 제한할 수도 있다. path 필드는 projected 볼륨의 마운트 위치에 대한
상대 경로를 지정한다.
참고: projected 볼륨 소스를 subPath 볼륨으로 마운트해서 사용하는 컨테이너는 해당 볼륨 소스의 업데이트를 수신하지 않는다.
Quobyte는 컨테이너 스토리지 인터페이스를 지원한다.
CSI 는 쿠버네티스 내에서 Quobyte 볼륨을 사용하기 위해 권장하는 플러그인이다. Quobyte의
깃헙 프로젝트에는 예시와 함께 CSI를 사용해서 Quobyte를 배포하기 위한 사용 설명서가 있다.
rbd
rbd 볼륨을 사용하면
Rados Block Device(RBD) 볼륨을 파드에 마운트할 수
있다. 파드를 제거할 때 지워지는 emptyDir 와는 다르게 rbd 볼륨의
내용은 유지되고, 볼륨은 마운트 해제만 된다. 이
의미는 RBD 볼륨에 데이터를 미리 채울 수 있으며, 데이터를
공유할 수 있다는 것이다.
참고: RBD를 사용하기 위해선 먼저 Ceph를 설치하고 실행해야 한다.
RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수
있다는 것이다. 즉, 데이터셋으로 볼륨을 미리 채운 다음, 필요한
만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도,
RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
동시 쓰기는 허용되지 않는다.
ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를
생성하는 소프트웨어 기반 스토리지 플랫폼이다. scaleIO 볼륨
플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수
있다. 퍼시스턴트 볼륨 클레임을 위해 새로운 볼륨을 동적으로 프로비저닝하는
방법에 대한 자세한 내용은
ScaleIO 퍼시스턴트 볼륨을 참고한다.
참고: 사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고
생성한 볼륨과 함께 실행해야 한다.
secret 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데
사용된다. 쿠버네티스 API에 시크릿을 저장하고 쿠버네티스에 직접적으로 연결하지 않고도
파드에서 사용할 수 있도록 파일로 마운트 할 수 있다. secret 볼륨은
tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토리지에 절대
기록되지 않는다.
참고: 사용하기 위해선 먼저 쿠버네티스 API에서 시크릿을 생성해야 한다.
참고: 시크릿을 subPath 볼륨 마운트로 사용하는 컨테이너는 시크릿
업데이트를 수신하지 못한다.
storageos 볼륨을 사용하면 기존 StorageOS
볼륨을 파드에 마운트할 수 있다.
StorageOS 는 쿠버네티스 환경에서 컨테이너로 실행되므로
쿠버네티스 클러스터의 모든 노드의 로컬 또는 연결된 스토리지에 접근할 수 있다.
노드 장애로부터 보호하기 위해 데이터를 복제할 수 있다. 씬(Thin) 프로비저닝과
압축은 활용률을 높이고 비용을 절감할 수 있게 한다.
StorageOS의 핵심은 컨테이너에 파일시스템을 통해 접근할 수 있는 블록 스토리지를 제공하는 것이다.
StorageOS 컨테이너는 64 비트 리눅스가 필요하고 추가적인 종속성이 없다.
무료 개발자 라이선스를 사용할 수 있다.
주의: StorageOS 볼륨에 접근하거나 스토리지 용량을
풀에 제공할 StorageOS 컨테이너를 실행해야 한다.
설치 설명서는
StorageOS 문서를 찾아본다.
vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk
vSphere VMDK 구성 예시
apiVersion:v1kind:Podmetadata:name:test-vmdkspec:containers:- image:k8s.gcr.io/test-webservername:test-containervolumeMounts:- mountPath:/test-vmdkname:test-volumevolumes:- name:test-volume# 이 VMDK 볼륨은 이미 있어야 한다.vsphereVolume:volumePath:"[DatastoreName] volumes/myDisk"fsType:ext4
vsphereVolume 용 CSIMigration 기능이 활성화되면, 기존 인-트리 플러그인에서
csi.vsphere.vmware.comCSI 드라이버로 모든 플러그인 작업을 리디렉션한다.
이 기능을 사용하려면,
vSphere CSI 드라이버가
클러스터에 설치되어야 하며 CSIMigration 및 CSIMigrationvSphere기능 게이트가 활성화되어 있어야 한다.
또한 최소 vSphere vCenter/ESXi 버전은 7.0u1이고 최소 HW 버전은 VM 버전 15여야 한다.
참고:
빌트인 vsphereVolume 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다.
diskformat
hostfailurestotolerate
forceprovisioning
cachereservation
diskstripes
objectspacereservation
iopslimit
이러한 파라미터를 사용하여 생성된 기존 볼륨은 vSphere CSI 드라이버로 마이그레이션되지만,
vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 따르지 않는다.
vSphere CSI 마이그레이션 완료
FEATURE STATE:Kubernetes v1.19 [beta]
vsphereVolume 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 true 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 csi.vsphere.vmware.comCSI 드라이버가 설치해야 한다.
subPath 사용하기
때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다.
volumeMounts.subPath 속성을 사용해서 root 대신 참조하는 볼륨 내의 하위 경로를
지정할 수 있다.
다음의 예시는 단일 공유 볼륨을 사용하여 LAMP 스택(리눅스 Apache MySQL PHP)이
있는 파드를 구성하는 방법을 보여준다. 이 샘플 subPath 구성은 프로덕션 용도로
권장되지 않는다.
PHP 애플리케이션의 코드와 자산은 볼륨의 html 폴더에 매핑되고
MySQL 데이터베이스는 볼륨의 mysql 폴더에 저장된다. 예를 들면 다음과 같다.
subPathExpr 필드를 사용해서 다운워드 API 환경 변수로부터
subPath 디렉터리 이름을 구성한다.
subPath 와 subPathExpr 속성은 상호 배타적이다.
이 예제는 Pod 가 subPathExpr 을 사용해서 hostPath 볼륨
/var/log/pods 내에 pod1 디렉터리를 만든다.
hostPath 볼륨은 downwardAPI 에서 Pod 이름을 사용한다.
호스트 디렉토리 /var/log/pods/pod1 은 컨테이너의 /logs 에 마운트된다.
apiVersion:v1kind:Podmetadata:name:pod1spec:containers:- name:container1env:- name:POD_NAMEvalueFrom:fieldRef:apiVersion:v1fieldPath:metadata.nameimage:busyboxcommand:["sh","-c","while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt"]volumeMounts:- name:workdir1mountPath:/logssubPathExpr:$(POD_NAME)restartPolicy:Nevervolumes:- name:workdir1hostPath:path:/var/log/pods
리소스
emptyDir 볼륨의 스토리지 매체(디스크나 SSD와 같은)는 kubelet root
디렉터리(보통 /var/lib/kubelet)를 보유한 파일시스템의
매체에 의해 결정 된다. emptyDir 또는 hostPath 볼륨이
사용할 수 있는 공간의 크기는 제한이 없으며, 컨테이너 간 또는 파드 간 격리는
없다.
아웃-오브-트리 볼륨 플러그인에는
컨테이너 스토리지 인터페이스(CSI) 그리고
FlexVolume이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에
추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다.
이전에는 모든 볼륨 플러그인이 "인-트리(in-tree)"에 있었다. "인-트리" 플러그인은 쿠버네티스 핵심 바이너리와
함께 빌드, 링크, 컴파일 및 배포되었다. 즉, 쿠버네티스(볼륨 플러그인)에
새로운 스토리지 시스템을 추가하려면 쿠버네티스 핵심 코드 리포지토리의 코드 확인이 필요했음을 의미한다.
CSI와 FlexVolume을 통해 쿠버네티스 코드 베이스와는
독립적으로 볼륨 플러그인을 개발하고, 쿠버네티스 클러스터의 확장으로 배포(설치)
할 수 있다.
driver: 사용할 볼륨 드라이버의 이름을 지정하는 문자열 값.
이 값은 CSI 사양에
정의된 CSI 드라이버가 GetPluginInfoResponse 에 반환하는 값과 일치해야 한다.
쿠버네티스에서 호출할 CSI 드라이버를 식별하고, CSI 드라이버 컴포넌트에서
CSI 드라이버에 속하는 PV 오브젝트를 식별하는데 사용한다.
volumeHandle: 볼륨을 식별하게 하는 고유한 문자열 값.
이 값은 CSI 사양에
정의된 CSI 드라이버가 CreateVolumeResponse 의 volume.id 필드에 반환하는 값과 일치해야 한다.
이 값은 볼륨을 참조할 때 CSI 볼륨 드라이버에 대한 모든 호출에
volume_id 값을 전달한다.
readOnly: 볼륨을 읽기 전용으로 "ControllerPublished" (연결)할지
여부를 나타내는 선택적인 불리언(boolean) 값. 기본적으로 false 이다. 이 값은
ControllerPublishVolumeRequest 의 readonly 필드를
통해 CSI 드라이버로 전달된다.
fsType: 만약 PV의 VolumeMode 가 Filesystem 인 경우에 이 필드는
볼륨을 마운트하는 데 사용해야 하는 파일시스템을 지정하는 데 사용될 수 있다. 만약
볼륨이 포맷되지 않았고 포맷이 지원되는 경우, 이 값은
볼륨을 포맷하는데 사용된다.
이 값은 ControllerPublishVolumeRequest, NodeStageVolumeRequest
그리고 NodePublishVolumeRequest 의 VolumeCapability
필드를 통해 CSI 드라이버로 전달된다.
volumeAttributes: 볼륨의 정적 속성을 지정하는 문자열과 문자열을
매핑한다. 이 매핑은 CSI 사양에
정의된 대로 CSI 드라이버의 CreateVolumeResponse 와 volume.attributes
필드에서 반환되는 매핑과 일치해야 한다.
이 매핑은 ControllerPublishVolumeRequest, NodeStageVolumeRequest,
그리고 NodePublishVolumeRequest 의 volume_context 필드를
통해 CSI 드라이버로 전달된다.
controllerPublishSecretRef: CSI의 ControllerPublishVolume
그리고 ControllerUnpublishVolume 호출을 완료하기 위해 CSI 드라이버에 전달하려는
민감한 정보가 포함된 시크릿 오브젝트에 대한 참조이다. 이 필드는
선택 사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에
둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다.
nodeStageSecretRef: CSI의 NodeStageVolume 호출을 완료하기위해
CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿
오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은
경우 비어있을 수 있다. 만약 시크릿에 둘 이상의 시크릿이 포함된 경우에도
모든 시크릿이 전달된다.
nodePublishSecretRef: CSI의 NodePublishVolume 호출을 완료하기위해
CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿
오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은
경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도
모든 시크릿이 전달된다.
CSI 원시(raw) 블록 볼륨 지원
FEATURE STATE:Kubernetes v1.18 [stable]
외부 CSI 드라이버가 있는 벤더들은 쿠버네티스 워크로드에서 원시(raw) 블록 볼륨
지원을 구현할 수 있다.
CSIMigration 기능이 활성화 되면 기존의 인-트리 플러그인에
대한 작업을 해당 CSI 플러그인(설치와 구성이 될 것으로 예상한)으로 유도한다.
결과적으로, 운영자는 인-트리 플러그인을 대체하는
CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임(인-트리 플러그인 참조)에
대한 구성 변경을 수행할 필요가 없다.
지원되는 작업 및 기능은 프로비저닝/삭제,
연결/분리, 마운트/마운트 해제 그리고 볼륨 크기 재조정이 포함된다.
CSIMigration 을 지원하고 해당 CSI 드라이버가 구현된 인-트리 플러그인은
볼륨 유형들에 나열되어 있다.
flexVolume
FlexVolume은 버전 1.2(CSI 이전) 이후 쿠버네티스에 존재하는
아웃-오브-트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에
접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드와 일부 경우에 컨트롤 플레인 노드의
미리 정의된 볼륨 플러그인 경로에 설치해야 한다.
파드는 flexvolume 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다.
더 자세한 내용은 FlexVolume 예제를 참고한다.
마운트 전파(propagation)
마운트 전파를 통해 컨테이너가 마운트한 볼륨을 동일한 파드의
다른 컨테이너 또는 동일한 노드의 다른 파드로 공유할 수 있다.
볼륨 마운트 전파는 Container.volumeMounts 의 mountPropagation 필드에
의해 제어된다. 그 값은 다음과 같다.
None - 이 볼륨 마운트는 호스트의 볼륨 또는 해당 서브디렉터리에
마운트된 것을 마운트 이후에 수신하지 않는다.
비슷한 방식으로, 컨테이너가 생성한 마운트는 호스트에서 볼 수 없다.
이것이 기본 모드이다.
경고:Bidirectional 마운트 전파는 위험할 수 있다. 이것은
호스트 운영체제를 손상시킬 수 있기에 권한이 있는 컨테이너에서만
허용된다. 리눅스 커널 동작을 숙지하는 것을 권장한다.
또한 파드 내 컨테이너에 의해 생성된 볼륨 마운트는 종료 시
컨테이너에 의해 파괴(마운트 해제)되어야 한다.
구성
일부 배포판(CoreOS, RedHat/Centos, Ubuntu)에서 마운트 전파가
제대로 작동하려면 아래와 같이 도커에서의 마운트 공유를
올바르게 구성해야 한다.
도커의 systemd 서비스 파일을 편집한다. MountFlags 를 다음과 같이 설정한다.
쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 VolumeSnapshot 을 나타낸다. 이 문서는 이미 쿠버네티스 퍼시스턴트 볼륨에 대해 잘 알고 있다고 가정한다.
소개
API 리소스 PersistentVolume 및 PersistentVolumeClaim 가 사용자 및 관리자가 볼륨을 프로비전할 때의 방법과 유사하게, VolumeSnapshotContent 및 VolumeSnapshot API 리소스는 볼륨 스냅샷을 생성하기 위해 제공된다.
VolumeSnapshotContent 는 관리자가 프로버져닝한 클러스터 볼륨에서의 스냅샷이다. 퍼시스턴트볼륨이 클러스터 리소스인 것처럼 이것 또한 클러스터 리소스이다.
VolumeSnapshot 은 사용자가 볼륨의 스냅샷을 요청할 수 있는 방법이다. 이는 퍼시스턴트볼륨클레임과 유사하다.
VolumeSnapshotClass 을 사용하면 VolumeSnapshot 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한 볼륨에서 가져온 스냅샷마다 다를 수 있으므로 PersistentVolumeClaim 의 StorageClass 를 사용하여 표현할 수는 없다.
볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는 표준화된 방법을 제공한다. 예를 들어, 데이터베이스 관리자는 이 기능을 사용하여 수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다.
사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다.
API 오브젝트인 VolumeSnapshot, VolumeSnapshotContent, VolumeSnapshotClass 는 핵심 API가 아닌, CRDs이다.
VolumeSnapshot 은 CSI 드라이버에서만 사용할 수 있다.
쿠버네티스 팀은 VolumeSnapshot 의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 VolumeSnapshot 및 VolumeSnapshotContent 오브젝트를 관찰하고 동적 프로비저닝에서 VolumeSnapshotContent 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 VolumeSnapshotContent 오브젝트를 관찰하고 CSI 엔드포인트에 대해 CreateSnapshot 및 DeleteSnapshot 을 트리거(trigger)한다.
스냅샷 오브젝트에 대한 강화된 검증을 제공하는 검증 웹훅 서버도 있다. 이는 CSI 드라이버가 아닌 스냅샷 컨트롤러 및 CRD와 함께 쿠버네티스 배포판에 의해 설치되어야 한다. 스냅샷 기능이 활성화된 모든 쿠버네티스 클러스터에 설치해야 한다.
CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 CSI 드라이버 문서를 확인하면 된다.
CRDs 및 스냅샷 컨트롤러는 쿠버네티스 배포 시 설치된다.
볼륨 스냅샷 및 볼륨 스냅샷 컨텐츠의 라이프사이클
VolumeSnapshotContents 은 클러스터 리소스이다. VolumeSnapshots 은 이러한 리소스의 요청이다. VolumeSnapshotContents 과 VolumeSnapshots의 상호 작용은 다음과 같은 라이프사이클을 따른다.
프로비저닝 볼륨 스냅샷
스냅샷을 프로비저닝할 수 있는 방법에는 사전 프로비저닝 혹은 동적 프로비저닝의 두 가지가 있다: .
사전 프로비전
클러스터 관리자는 많은 VolumeSnapshotContents 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다.
동적
사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. 볼륨스냅샷클래스는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다.
바인딩
스냅샷 컨트롤러는 사전 프로비저닝과 동적 프로비저닝된 시나리오에서 VolumeSnapshot 오브젝트와 적절한 VolumeSnapshotContent 오브젝트와의 바인딩을 처리한다. 바인딩은 1:1 매핑이다.
사전 프로비저닝된 경우, 볼륨스냅샷은 볼륨스냅샷컨텐츠 오브젝트 생성이 요청될 때까지 바인드되지 않은 상태로 유지된다.
스냅샷 소스 보호로서의 퍼시스턴트 볼륨 클레임
이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인
퍼시스턴트볼륨클레임
API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에).
퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.
삭제
삭제는 VolumeSnapshot 를 삭제 시 트리거로 DeletionPolicy 가 실행된다. DeletionPolicy 가 Delete 라면, 기본 스토리지 스냅샷이 VolumeSnapshotContent 오브젝트와 함께 삭제될 것이다. DeletionPolicy 이 Retain 이라면, 기본 스트리지 스냅샷과 VolumeSnapshotContent 둘 다 유지된다.
이 페이지는 쿠버네티스의 퍼시스턴트 볼륨 의 현재 상태를 설명한다. 볼륨에 대해 익숙해지는 것을 추천한다.
소개
스토리지 관리는 컴퓨트 인스턴스 관리와는 별개의 문제다. 퍼시스턴트볼륨 서브시스템은 사용자 및 관리자에게 스토리지 사용 방법에서부터 스토리지가 제공되는 방법에 대한 세부 사항을 추상화하는 API를 제공한다. 이를 위해 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이라는 두 가지 새로운 API 리소스를 소개한다.
퍼시스턴트볼륨 (PV)은 관리자가 프로비저닝하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다.
퍼시스턴트볼륨클레임 (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: ReadWriteOnce, ReadOnlyMany 또는 ReadWriteMany로 마운트 할 수 있음. AccessModes 참고).
퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 스토리지클래스 리소스가 있다.
PV는 클러스터 리소스이다. PVC는 해당 리소스에 대한 요청이며 리소스에 대한 클레임 검사 역할을 한다. PV와 PVC 간의 상호 작용은 다음 라이프사이클을 따른다.
프로비저닝
PV를 프로비저닝 할 수 있는 두 가지 방법이 있다: 정적(static) 프로비저닝과 동적(dynamic) 프로비저닝
정적 프로비저닝
클러스터 관리자는 여러 PV를 만든다. 클러스터 사용자가 사용할 수 있는 실제 스토리지의 세부 사항을 제공한다. 이 PV들은 쿠버네티스 API에 존재하며 사용할 수 있다.
동적 프로비저닝
관리자가 생성한 정적 PV가 사용자의 퍼시스턴트볼륨클레임과 일치하지 않으면
클러스터는 PVC를 위해 특별히 볼륨을 동적으로 프로비저닝 하려고 시도할 수 있다.
이 프로비저닝은 스토리지클래스를 기반으로 한다. PVC는
스토리지 클래스를
요청해야 하며 관리자는 동적 프로비저닝이 발생하도록 해당 클래스를 생성하고 구성해야 한다.
"" 클래스를 요청하는 클레임은 동적 프로비저닝을 효과적으로
비활성화한다.
스토리지 클래스를 기반으로 동적 스토리지 프로비저닝을 사용하려면 클러스터 관리자가 API 서버에서
DefaultStorageClass어드미션 컨트롤러를 사용하도록 설정해야 한다.
예를 들어 API 서버 컴포넌트의 --enable-admission-plugins 플래그에 대한 쉼표로 구분되어
정렬된 값들의 목록 중에 DefaultStorageClass가 포함되어 있는지 확인하여 설정할 수 있다.
API 서버 커맨드라인 플래그에 대한 자세한 정보는
kube-apiserver 문서를 확인하면 된다.
바인딩
사용자는 원하는 특정 용량의 스토리지와 특정 접근 모드로 퍼시스턴트볼륨클레임을 생성하거나 동적 프로비저닝의 경우 이미 생성한 상태다. 마스터의 컨트롤 루프는 새로운 PVC를 감시하고 일치하는 PV(가능한 경우)를 찾아 서로 바인딩한다. PV가 새 PVC에 대해 동적으로 프로비저닝된 경우 루프는 항상 해당 PV를 PVC에 바인딩한다. 그렇지 않으면 사용자는 항상 최소한 그들이 요청한 것을 얻지만 볼륨은 요청된 것을 초과할 수 있다. 일단 바인딩되면 퍼시스턴트볼륨클레임은 어떻게 바인딩되었는지 상관없이 배타적으로 바인딩된다. PVC 대 PV 바인딩은 일대일 매핑으로, 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임 사이의 양방향 바인딩인 ClaimRef를 사용한다.
일치하는 볼륨이 없는 경우 클레임은 무한정 바인딩되지 않은 상태로 남아 있다. 일치하는 볼륨이 제공되면 클레임이 바인딩된다. 예를 들어 많은 수의 50Gi PV로 프로비저닝된 클러스터는 100Gi를 요청하는 PVC와 일치하지 않는다. 100Gi PV가 클러스터에 추가되면 PVC를 바인딩할 수 있다.
사용 중
파드는 클레임을 볼륨으로 사용한다. 클러스터는 클레임을 검사하여 바인딩된 볼륨을 찾고 해당 볼륨을 파드에 마운트한다. 여러 접근 모드를 지원하는 볼륨의 경우 사용자는 자신의 클레임을 파드에서 볼륨으로 사용할 때 원하는 접근 모드를 지정한다.
일단 사용자에게 클레임이 있고 그 클레임이 바인딩되면, 바인딩된 PV는 사용자가 필요로 하는 한 사용자에게 속한다. 사용자는 파드의 volumes 블록에 persistentVolumeClaim을 포함하여 파드를 스케줄링하고 클레임한 PV에 접근한다. 이에 대한 자세한 내용은 볼륨으로 클레임하기를 참고하길 바란다.
사용 중인 스토리지 오브젝트 보호
사용 중인 스토리지 오브젝트 보호 기능의 목적은 PVC에 바인딩된 파드와 퍼시스턴트볼륨(PV)이 사용 중인 퍼시스턴트볼륨클레임(PVC)을 시스템에서 삭제되지 않도록 하는 것이다. 삭제되면 이로 인해 데이터의 손실이 발생할 수 있기 때문이다.
참고: PVC를 사용하는 파드 오브젝트가 존재하면 파드가 PVC를 사용하고 있는 상태이다.
사용자가 파드에서 활발하게 사용 중인 PVC를 삭제하면 PVC는 즉시 삭제되지 않는다. PVC가 더 이상 파드에서 적극적으로 사용되지 않을 때까지 PVC 삭제가 연기된다. 또한 관리자가 PVC에 바인딩된 PV를 삭제하면 PV는 즉시 삭제되지 않는다. PV가 더 이상 PVC에 바인딩되지 않을 때까지 PV 삭제가 연기된다.
PVC의 상태가 Terminating이고 Finalizers 목록에 kubernetes.io/pvc-protection이 포함되어 있으면 PVC가 보호된 것으로 볼 수 있다.
사용자가 볼륨을 다 사용하고나면 리소스를 반환할 수 있는 API를 사용하여 PVC 오브젝트를 삭제할 수 있다. 퍼시스턴트볼륨의 반환 정책은 볼륨에서 클레임을 해제한 후 볼륨에 수행할 작업을 클러스터에 알려준다. 현재 볼륨에 대한 반환 정책은 Retain, Recycle, 그리고 Delete가 있다.
Retain(보존)
Retain 반환 정책은 리소스를 수동으로 반환할 수 있게 한다. 퍼시스턴트볼륨클레임이 삭제되면 퍼시스턴트볼륨은 여전히 존재하며 볼륨은 "릴리스 된" 것으로 간주된다. 그러나 이전 요청자의 데이터가 여전히 볼륨에 남아 있기 때문에 다른 요청에 대해서는 아직 사용할 수 없다. 관리자는 다음 단계에 따라 볼륨을 수동으로 반환할 수 있다.
퍼시스턴트볼륨을 삭제한다. PV가 삭제된 후에도 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산이 존재한다.
관련 스토리지 자산의 데이터를 수동으로 삭제한다.
연결된 스토리지 자산을 수동으로 삭제하거나 동일한 스토리지 자산을 재사용하려는 경우 스토리지 자산 정의로 새 퍼시스턴트볼륨을 생성한다.
Delete(삭제)
Delete 반환 정책을 지원하는 볼륨 플러그인의 경우, 삭제는 쿠버네티스에서 퍼시스턴트볼륨 오브젝트와 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝된 볼륨은 스토리지클래스의 반환 정책을 상속하며 기본값은 Delete이다. 관리자는 사용자의 기대에 따라 스토리지클래스를 구성해야 한다. 그렇지 않으면 PV를 생성한 후 PV를 수정하거나 패치해야 한다. 퍼시스턴트볼륨의 반환 정책 변경을 참고하길 바란다.
Recycle(재활용)
경고:Recycle 반환 정책은 더 이상 사용하지 않는다. 대신 권장되는 방식은 동적 프로비저닝을 사용하는 것이다.
기본 볼륨 플러그인에서 지원하는 경우 Recycle 반환 정책은 볼륨에서 기본 스크럽(rm -rf /thevolume/*)을 수행하고 새 클레임에 다시 사용할 수 있도록 한다.
그러나 관리자는 레퍼런스에
설명된 대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를
사용하여 사용자 정의 재활용 파드 템플릿을 구성할 수 있다.
사용자 정의 재활용 파드 템플릿에는 아래 예와 같이 volumes 명세가
포함되어야 한다.
퍼시스턴트볼륨클레임에서 퍼시스턴트볼륨을 지정하여, 특정 PV와 PVC 간의 바인딩을 선언한다.
퍼시스턴트볼륨이 존재하고 claimRef 필드를 통해 퍼시스턴트볼륨클레임을 예약하지 않은 경우, 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이 바인딩된다.
바인딩은 노드 선호도(affinity)를 포함하여 일부 볼륨 일치(matching) 기준과 관계없이 발생한다.
컨트롤 플레인은 여전히 스토리지 클래스, 접근 모드 및 요청된 스토리지 크기가 유효한지 확인한다.
apiVersion:v1kind:PersistentVolumeClaimmetadata:name:foo-pvcnamespace:foospec:storageClassName:""# 빈 문자열은 명시적으로 설정해야 하며 그렇지 않으면 기본 스토리지클래스가 설정됨volumeName:foo-pv...
이 메서드는 퍼시스턴트볼륨에 대한 바인딩 권한을 보장하지 않는다. 다른 퍼시스턴트볼륨클레임에서 지정한 PV를 사용할 수 있는 경우, 먼저 해당 스토리지 볼륨을 예약해야 한다. PV의 claimRef 필드에 관련 퍼시스턴트볼륨클레임을 지정하여 다른 PVC가 바인딩할 수 없도록 한다.
PVC에 대해 더 큰 볼륨을 요청하려면 PVC 오브젝트를 수정하여 더 큰 용량을
지정한다. 이는 기본 퍼시스턴트볼륨을 지원하는 볼륨의 확장을 트리거한다. 클레임을 만족시키기 위해
새로운 퍼시스턴트볼륨이 생성되지 않고 기존 볼륨의 크기가 조정된다.
CSI 볼륨 확장
FEATURE STATE:Kubernetes v1.16 [beta]
CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확장을 지원하려면 특정 CSI 드라이버도 필요하다. 자세한 내용은 특정 CSI 드라이버 문서를 참고한다.
파일시스템을 포함하는 볼륨 크기 조정
파일시스템이 XFS, Ext3 또는 Ext4 인 경우에만 파일시스템을 포함하는 볼륨의 크기를 조정할 수 있다.
볼륨에 파일시스템이 포함된 경우 새 파드가 ReadWrite 모드에서 퍼시스턴트볼륨클레임을 사용하는
경우에만 파일시스템의 크기가 조정된다. 파일시스템 확장은 파드가 시작되거나
파드가 실행 중이고 기본 파일시스템이 온라인 확장을 지원할 때 수행된다.
FlexVolumes는 RequiresFSResize 기능으로 드라이버가 true로 설정된 경우 크기 조정을 허용한다.
FlexVolume은 파드 재시작 시 크기를 조정할 수 있다.
사용 중인 퍼시스턴트볼륨클레임 크기 조정
FEATURE STATE:Kubernetes v1.15 [beta]
참고: 사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. ExpandInUsePersistentVolumes 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 기능 게이트 문서를 참고한다.
이 경우 기존 PVC를 사용하는 파드 또는 디플로이먼트를 삭제하고 다시 만들 필요가 없다.
파일시스템이 확장되자마자 사용 중인 PVC가 파드에서 자동으로 사용 가능하다.
이 기능은 파드나 디플로이먼트에서 사용하지 않는 PVC에는 영향을 미치지 않는다. 확장을 완료하기 전에
PVC를 사용하는 파드를 만들어야 한다.
다른 볼륨 유형과 비슷하게 FlexVolume 볼륨도 파드에서 사용 중인 경우 확장할 수 있다.
참고: FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하는 경우에만 가능하다.
참고: EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터가 있다.
볼륨 확장 시 오류 복구
기본 스토리지 확장에 실패하면, 클러스터 관리자가 수동으로 퍼시스턴트 볼륨 클레임(PVC) 상태를 복구하고 크기 조정 요청을 취소할 수 있다. 그렇지 않으면, 컨트롤러가 관리자 개입 없이 크기 조정 요청을 계속해서 재시도한다.
퍼시스턴트볼륨클레임(PVC)에 바인딩된 퍼시스턴트볼륨(PV)을 Retain 반환 정책으로 표시한다.
PVC를 삭제한다. PV에는 Retain 반환 정책이 있으므로 PVC를 재생성할 때 데이터가 손실되지 않는다.
새 PVC를 바인딩할 수 있도록 PV 명세에서 claimRef 항목을 삭제한다. 그러면 PV가 Available 상태가 된다.
PV 보다 작은 크기로 PVC를 다시 만들고 PVC의 volumeName 필드를 PV 이름으로 설정한다. 이것은 새 PVC를 기존 PV에 바인딩해야 한다.
PV의 반환 정책을 복원하는 것을 잊지 않는다.
퍼시스턴트 볼륨의 유형
퍼시스턴트볼륨 유형은 플러그인으로 구현된다. 쿠버네티스는 현재 다음의 플러그인을 지원한다.
참고: 클러스터 내에서 퍼시스턴트볼륨을 사용하려면 볼륨 유형과 관련된 헬퍼(Helper) 프로그램이 필요할 수 있다. 이 예에서 퍼시스턴트볼륨은 NFS 유형이며 NFS 파일시스템 마운트를 지원하려면 헬퍼 프로그램인 /sbin/mount.nfs가 필요하다.
용량
일반적으로 PV는 특정 저장 용량을 가진다. 이것은 PV의 capacity 속성을 사용하여 설정된다. capacity가 사용하는 단위를 이해하려면 쿠버네티스 리소스 모델을 참고한다.
현재 스토리지 용량 크기는 설정하거나 요청할 수 있는 유일한 리소스이다. 향후 속성에 IOPS, 처리량 등이 포함될 수 있다.
볼륨 모드
FEATURE STATE:Kubernetes v1.18 [stable]
쿠버네티스는 퍼시스턴트볼륨의 두 가지 volumeModes인 Filesystem과 Block을 지원한다.
volumeMode는 선택적 API 파라미터이다.
Filesystem은 volumeMode 파라미터가 생략될 때 사용되는 기본 모드이다.
volumeMode: Filesystem이 있는 볼륨은 파드의 디렉터리에 마운트 된다. 볼륨이 장치에
의해 지원되고 그 장치가 비어 있으면 쿠버네티스는 장치를
처음 마운트하기 전에 장치에 파일시스템을 만든다.
볼륨을 원시 블록 장치로 사용하려면 volumeMode의 값을 Block으로 설정할 수 있다.
이러한 볼륨은 파일시스템이 없는 블록 장치로 파드에 제공된다.
이 모드는 파드와 볼륨 사이에 파일시스템 계층 없이도 볼륨에 액세스하는
가장 빠른 방법을 파드에 제공하는 데 유용하다. 반면에 파드에서 실행되는 애플리케이션은
원시 블록 장치를 처리하는 방법을 알아야 한다.
파드에서 volumeMode: Block으로 볼륨을 사용하는 방법에 대한 예는
원시 블록 볼륨 지원를 참조하십시오.
접근 모드
리소스 제공자가 지원하는 방식으로 호스트에 퍼시스턴트볼륨을 마운트할 수 있다. 아래 표에서 볼 수 있듯이 제공자들은 서로 다른 기능을 가지며 각 PV의 접근 모드는 해당 볼륨에서 지원하는 특정 모드로 설정된다. 예를 들어 NFS는 다중 읽기/쓰기 클라이언트를 지원할 수 있지만 특정 NFS PV는 서버에서 읽기 전용으로 export할 수 있다. 각 PV는 특정 PV의 기능을 설명하는 자체 접근 모드 셋을 갖는다.
접근 모드는 다음과 같다.
ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다
ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany
중요! 볼륨이 여러 접근 모드를 지원하더라도 한 번에 하나의 접근 모드를 사용하여 마운트할 수 있다. 예를 들어 GCEPersistentDisk는 하나의 노드가 ReadWriteOnce로 마운트하거나 여러 노드가 ReadOnlyMany로 마운트할 수 있지만 동시에는 불가능하다.
Volume Plugin
ReadWriteOnce
ReadOnlyMany
ReadWriteMany
AWSElasticBlockStore
✓
-
-
AzureFile
✓
✓
✓
AzureDisk
✓
-
-
CephFS
✓
✓
✓
Cinder
✓
-
-
CSI
드라이버에 따라 다름
드라이버에 따라 다름
드라이버에 따라 다름
FC
✓
✓
-
FlexVolume
✓
✓
드라이버에 따라 다름
Flocker
✓
-
-
GCEPersistentDisk
✓
✓
-
Glusterfs
✓
✓
✓
HostPath
✓
-
-
iSCSI
✓
✓
-
Quobyte
✓
✓
✓
NFS
✓
✓
✓
RBD
✓
✓
-
VsphereVolume
✓
-
- (파드가 병치될(collocated) 때 작동)
PortworxVolume
✓
-
✓
ScaleIO
✓
✓
-
StorageOS
✓
-
-
클래스
PV는 storageClassName 속성을
스토리지클래스의
이름으로 설정하여 지정하는 클래스를 가질 수 있다.
특정 클래스의 PV는 해당 클래스를 요청하는 PVC에만 바인딩될 수 있다.
storageClassName이 없는 PV에는 클래스가 없으며 특정 클래스를 요청하지 않는 PVC에만
바인딩할 수 있다.
이전에는 volume.beta.kubernetes.io/storage-class 어노테이션이
storageClassName 속성 대신 사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만,
향후 쿠버네티스 릴리스에서 완전히 사용 중단(deprecated)이 될 예정이다.
반환 정책
현재 반환 정책은 다음과 같다.
Retain(보존) -- 수동 반환
Recycle(재활용) -- 기본 스크럽 (rm -rf /thevolume/*)
Delete(삭제) -- AWS EBS, GCE PD, Azure Disk 또는 OpenStack Cinder 볼륨과 같은 관련 스토리지 자산이 삭제됨
현재 NFS 및 HostPath만 재활용을 지원한다. AWS EBS, GCE PD, Azure Disk 및 Cinder 볼륨은 삭제를 지원한다.
마운트 옵션
쿠버네티스 관리자는 퍼시스턴트 볼륨이 노드에 마운트될 때 추가 마운트 옵션을 지정할 수 있다.
이전에는 mountOptions 속성 대신 volume.beta.kubernetes.io/mount-options 어노테이션이
사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만,
향후 쿠버네티스 릴리스에서 완전히 사용 중단(deprecated)이 될 예정이다.
노드 어피니티(affinity)
참고: 대부분의 볼륨 유형의 경우 이 필드를 설정할 필요가 없다. AWS EBS, GCE PD 및 Azure Disk 볼륨 블록 유형에 자동으로 채워진다. 로컬 볼륨에 대해서는 이를 명시적으로 설정해야 한다.
PV는 노드 어피니티를 지정하여 이 볼륨에 접근할 수 있는 노드를 제한하는 제약 조건을 정의할 수 있다. PV를 사용하는 파드는 노드 어피니티에 의해 선택된 노드로만 스케줄링된다.
단계(Phase)
볼륨은 다음 단계 중 하나이다.
Available(사용 가능) -– 아직 클레임에 바인딩되지 않은 사용할 수 있는 리소스
Bound(바인딩) –- 볼륨이 클레임에 바인딩됨
Released(릴리스) –- 클레임이 삭제되었지만 클러스터에서 아직 리소스를 반환하지 않음
Failed(실패) –- 볼륨이 자동 반환에 실패함
CLI는 PV에 바인딩된 PVC의 이름을 표시한다.
퍼시스턴트볼륨클레임
각 PVC에는 스펙과 상태(클레임의 명세와 상태)가 포함된다.
퍼시스턴트볼륨클레임 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
apiVersion:v1kind:PersistentVolumeClaimmetadata:name:myclaimspec:accessModes:- ReadWriteOncevolumeMode:Filesystemresources:requests:storage:8GistorageClassName:slowselector:matchLabels:release:"stable"matchExpressions:- {key: environment, operator: In, values:[dev]}
접근 모드
클레임은 특정 접근 모드로 저장소를 요청할 때 볼륨과 동일한 규칙을 사용한다.
볼륨 모드
클레임은 볼륨과 동일한 규칙을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다.
리소스
파드처럼 클레임은 특정 수량의 리소스를 요청할 수 있다. 이 경우는 스토리지에 대한 요청이다. 동일한 리소스 모델이 볼륨과 클레임 모두에 적용된다.
셀렉터
클레임은 볼륨 셋을 추가로 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 레이블이 셀렉터와 일치하는 볼륨만 클레임에 바인딩할 수 있다. 셀렉터는 두 개의 필드로 구성될 수 있다.
matchLabels - 볼륨에 이 값의 레이블이 있어야함
matchExpressions - 키, 값의 목록, 그리고 키와 값에 관련된 연산자를 지정하여 만든 요구 사항 목록. 유효한 연산자에는 In, NotIn, Exists 및 DoesNotExist가 있다.
matchLabels 및 matchExpressions의 모든 요구 사항이 AND 조건이다. 일치하려면 모두 충족해야 한다.
클래스
클레임은 storageClassName 속성을 사용하여
스토리지클래스의 이름을 지정하여
특정 클래스를 요청할 수 있다.
요청된 클래스의 PV(PVC와 동일한 storageClassName을 갖는 PV)만 PVC에
바인딩될 수 있다.
PVC는 반드시 클래스를 요청할 필요는 없다. storageClassName이 ""로 설정된
PVC는 항상 클래스가 없는 PV를 요청하는 것으로 해석되므로
클래스가 없는 PV(어노테이션이 없거나 ""와 같은 하나의 셋)에만 바인딩될 수
있다. storageClassName이 없는 PVC는
DefaultStorageClass 어드미션 플러그인이
켜져 있는지 여부에 따라 동일하지 않으며
클러스터에 따라 다르게 처리된다.
어드미션 플러그인이 켜져 있으면 관리자가 기본 스토리지클래스를 지정할 수 있다.
storageClassName이 없는 모든 PVC는 해당 기본값의 PV에만 바인딩할 수 있다. 기본
스토리지클래스 지정은 스토리지클래스 오브젝트에서 어노테이션
storageclass.kubernetes.io/is-default-class를 true로
설정하여 수행된다. 관리자가 기본값을 지정하지 않으면 어드미션 플러그인이 꺼져 있는 것처럼
클러스터가 PVC 생성에 응답한다. 둘 이상의 기본값이 지정된 경우 어드미션
플러그인은 모든 PVC 생성을
금지한다.
어드미션 플러그인이 꺼져 있으면 기본 스토리지클래스에 대한 기본값 자체가 없다.
storageClassName이 없는 모든 PVC는 클래스가 없는 PV에만 바인딩할 수 있다. 이 경우
storageClassName이 없는 PVC는 storageClassName이 ""로 설정된 PVC와
같은 방식으로 처리된다.
설치 방법에 따라 설치 중에 애드온 관리자가 기본 스토리지클래스를 쿠버네티스 클러스터에
배포할 수 있다.
PVC가 스토리지클래스를 요청하는 것 외에도 selector를 지정하면 요구 사항들이
AND 조건으로 동작한다. 요청된 클래스와 요청된 레이블이 있는 PV만 PVC에
바인딩될 수 있다.
참고: 현재 비어 있지 않은 selector가 있는 PVC에는 PV를 동적으로 프로비저닝할 수 없다.
이전에는 volume.beta.kubernetes.io/storage-class 어노테이션이 storageClassName
속성 대신 사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만,
향후 쿠버네티스 릴리스에서는 지원되지 않는다.
볼륨으로 클레임하기
클레임을 볼륨으로 사용해서 파드가 스토리지에 접근한다. 클레임은 클레임을 사용하는 파드와 동일한 네임스페이스에 있어야 한다. 클러스터는 파드의 네임스페이스에서 클레임을 찾고 이를 사용하여 클레임과 관련된 퍼시스턴트볼륨을 얻는다. 그런 다음 볼륨이 호스트와 파드에 마운트된다.
참고: 파드에 대한 원시 블록 장치를 추가할 때 마운트 경로 대신 컨테이너에 장치 경로를 지정한다.
블록 볼륨 바인딩
사용자가 퍼시스턴트볼륨클레임 스펙에서 volumeMode 필드를 사용하여 이를 나타내는 원시 블록 볼륨을 요청하는 경우 바인딩 규칙은 스펙의 일부분으로 이 모드를 고려하지 않은 이전 릴리스에 비해 약간 다르다.
사용자와 관리자가 원시 블록 장치를 요청하기 위해 지정할 수 있는 가능한 조합의 표가 아래 나열되어 있다. 이 테이블은 볼륨이 바인딩되는지 여부를 나타낸다.
정적 프로비저닝된 볼륨에 대한 볼륨 바인딩 매트릭스이다.
PV volumeMode
PVC volumeMode
Result
지정되지 않음
지정되지 않음
BIND
지정되지 않음
Block
NO BIND
지정되지 않음
Filesystem
BIND
Block
지정되지 않음
NO BIND
Block
Block
BIND
Block
Filesystem
NO BIND
Filesystem
Filesystem
BIND
Filesystem
Block
NO BIND
Filesystem
지정되지 않음
BIND
참고: 알파 릴리스에서는 정적으로 프로비저닝된 볼륨만 지원된다. 관리자는 원시 블록 장치로 작업할 때 이러한 값을 고려해야 한다.
볼륨 스냅샷 및 스냅샷 지원에서 볼륨 복원
FEATURE STATE:Kubernetes v1.20 [stable]
볼륨 스냅 샷은 아웃-오브-트리 CSI 볼륨 플러그인만 지원한다. 자세한 내용은 볼륨 스냅샷을 참조한다.
인-트리 볼륨 플러그인은 사용 중단 되었다. 볼륨 플러그인 FAQ에서 사용 중단된 볼륨 플러그인에 대해 확인할 수 있다.
광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한
구성 템플릿 또는 예제를 작성하는 경우 다음 패턴을 사용하는 것이 좋다.
구성 번들(디플로이먼트, 컨피그맵 등)에 퍼시스턴트볼륨클레임
오브젝트를 포함시킨다.
구성을 인스턴스화 하는 사용자에게 퍼시스턴트볼륨을 생성할 권한이 없을 수 있으므로
퍼시스턴트볼륨 오브젝트를 구성에 포함하지 않는다.
템플릿을 인스턴스화 할 때 스토리지 클래스 이름을 제공하는 옵션을
사용자에게 제공한다.
사용자가 스토리지 클래스 이름을 제공하는 경우 해당 값을
permanentVolumeClaim.storageClassName 필드에 입력한다.
클러스터에서 관리자가 스토리지클래스를 활성화한 경우
PVC가 올바른 스토리지 클래스와 일치하게 된다.
사용자가 스토리지 클래스 이름을 제공하지 않으면
permanentVolumeClaim.storageClassName 필드를 nil로 남겨둔다.
그러면 클러스터에 기본 스토리지클래스가 있는 사용자에 대해 PV가 자동으로 프로비저닝된다.
많은 클러스터 환경에 기본 스토리지클래스가 설치되어 있거나 관리자가
고유한 기본 스토리지클래스를 생성할 수 있다.
도구(tooling)에서 일정 시간이 지나도 바인딩되지 않는 PVC를 관찰하여 사용자에게
노출시킨다. 이는 클러스터가 동적 스토리지를 지원하지
않거나(이 경우 사용자가 일치하는 PV를 생성해야 함),
클러스터에 스토리지 시스템이 없음을 나타낸다(이 경우
사용자는 PVC가 필요한 구성을 배포할 수 없음).
참고:spec.resources.requests.storage 에 용량 값을 지정해야 하며, 지정한 값은 소스 볼륨의 용량과 같거나 또는 더 커야 한다.
그 결과로 지정된 소스 pvc-1 과 동일한 내용을 가진 clone-of-pvc-1 이라는 이름을 가지는 새로운 PVC가 생겨난다.
사용
새 PVC를 사용할 수 있게 되면, 복제된 PVC는 다른 PVC와 동일하게 소비된다. 또한, 이 시점에서 새롭게 생성된 PVC는 독립된 오브젝트이다. 원본 dataSource PVC와는 무관하게 독립적으로 소비하고, 복제하고, 스냅샷의 생성 또는 삭제를 할 수 있다. 이는 소스가 새롭게 생성된 복제본에 어떤 방식으로든 연결되어 있지 않으며, 새롭게 생성된 복제본에 영향 없이 수정하거나, 삭제할 수도 있는 것을 의미한다.
3.6.5 - 볼륨 스냅샷 클래스
이 문서는 쿠버네티스의 볼륨스냅샷클래스(VolumeSnapshotClass) 개요를 설명한다.
볼륨 스냅샷과
스토리지 클래스의 숙지를 추천한다.
소개
스토리지클래스(StorageClass)는 관리자가 볼륨을 프로비저닝할 때 제공하는 스토리지의 "클래스"를
설명하는 방법을 제공하는 것처럼, 볼륨스냅샷클래스는 볼륨 스냅샷을
프로비저닝할 때 스토리지의 "클래스"를 설명하는 방법을 제공한다.
VolumeSnapshotClass 리소스
각 볼륨스냅샷클래스에는 클래스에 속하는 볼륨스냅샷을
동적으로 프로비전 할 때 사용되는 driver, deletionPolicy 그리고 parameters
필드를 포함한다.
볼륨스냅샷클래스 오브젝트의 이름은 중요하며, 사용자가 특정
클래스를 요청할 수 있는 방법이다. 관리자는 볼륨스냅샷클래스 오브젝트를
처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가
생성된 이후에는 업데이트할 수 없다.
볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을
결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야 한다.
삭제정책(DeletionPolicy)
볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩된 볼륨스냅샷 오브젝트를 삭제할 때 VolumeSnapshotContent의 상황을 구성할 수 있다. 볼륨 스냅샷 클래스의 삭제정책은 Retain 또는 Delete 일 수 있다. 이 필드는 반드시 지정해야 한다.
삭제정책이 Delete 인 경우 기본 스토리지 스냅샷이 VolumeSnapshotContent 오브젝트와 함께 삭제된다. 삭제정책이 Retain 인 경우 기본 스냅샷과 VolumeSnapshotContent 모두 유지된다.
파라미터
볼륨 스냅샷 클래스에는 볼륨 스냅샷 클래스에 속하는 볼륨 스냅샷을
설명하는 파라미터를 가지고 있다. driver 에 따라 다른 파라미터를 사용할
수 있다.
3.6.6 - 스토리지 클래스
이 문서는 쿠버네티스의 스토리지클래스의 개념을 설명한다.
볼륨과
퍼시스턴트 볼륨에 익숙해지는 것을 권장한다.
소개
스토리지클래스는 관리자가 제공하는 스토리지의 "classes"를 설명할 수 있는
방법을 제공한다. 다른 클래스는 서비스의 품질 수준 또는
백업 정책, 클러스터 관리자가 정한 임의의 정책에
매핑될 수 있다. 쿠버네티스 자체는 클래스가 무엇을 나타내는지에
대해 상관하지 않는다. 다른 스토리지 시스템에서는 이 개념을
"프로파일"이라고도 한다.
스토리지클래스 리소스
각 스토리지클래스에는 해당 스토리지클래스에 속하는 퍼시스턴트볼륨을 동적으로 프로비저닝
할 때 사용되는 provisioner, parameters 와
reclaimPolicy 필드가 포함된다.
스토리지클래스 오브젝트의 이름은 중요하며, 사용자가 특정
클래스를 요청할 수 있는 방법이다. 관리자는 스토리지클래스 오브젝트를
처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하며,
일단 생성된 오브젝트는 업데이트할 수 없다.
관리자는 특정 클래스에 바인딩을 요청하지 않는 PVC에 대해서만 기본
스토리지클래스를 지정할 수 있다. 자세한 내용은
퍼시스턴트볼륨클레임 섹션을
본다.
예를 들어, NFS는 내부 프로비저너를 제공하지 않지만, 외부
프로비저너를 사용할 수 있다. 타사 스토리지 업체가 자체 외부
프로비저너를 제공하는 경우도 있다.
리클레임 정책
스토리지클래스에 의해 동적으로 생성된 퍼시스턴트볼륨은 클래스의
reclaimPolicy 필드에 지정된 리클레임 정책을 가지는데,
이는 Delete 또는 Retain 이 될 수 있다. 스토리지클래스 오브젝트가
생성될 때 reclaimPolicy 가 지정되지 않으면 기본값은 Delete 이다.
수동으로 생성되고 스토리지클래스를 통해 관리되는 퍼시스턴트볼륨에는
생성 시 할당된 리클레임 정책이 있다.
볼륨 확장 허용
FEATURE STATE:Kubernetes v1.11 [beta]
퍼시스턴트볼륨은 확장이 가능하도록 구성할 수 있다. 이 기능을 true 로 설정하면
해당 PVC 오브젝트를 편집하여 볼륨 크기를 조정할 수 있다.
다음 볼륨 유형은 기본 스토리지클래스에서 allowVolumeExpansion 필드가
true로 설정된 경우 볼륨 확장을 지원한다.
Table of Volume types and the version of Kubernetes they require
볼륨 유형
요구되는 쿠버네티스 버전
gcePersistentDisk
1.11
awsElasticBlockStore
1.11
Cinder
1.11
glusterfs
1.11
rbd
1.11
Azure File
1.11
Azure Disk
1.11
Portworx
1.11
FlexVolume
1.13
CSI
1.14 (alpha), 1.16 (beta)
참고: 볼륨 확장 기능을 사용해서 볼륨을 확장할 수 있지만, 볼륨을 축소할 수는 없다.
마운트 옵션
스토리지클래스에 의해 동적으로 생성된 퍼시스턴트볼륨은
클래스의 mountOptions 필드에 지정된 마운트 옵션을 가진다.
만약 볼륨 플러그인이 마운트 옵션을 지원하지 않는데, 마운트
옵션을 지정하면 프로비저닝은 실패한다. 마운트 옵션은 클래스 또는 PV에서
검증되지 않는다. PV 마운트가 유효하지 않으면, 마운트가 실패하게 된다.
기본적으로, Immediate 모드는 퍼시스턴트볼륨클레임이 생성되면 볼륨
바인딩과 동적 프로비저닝이 즉시 발생하는 것을 나타낸다. 토폴로지 제약이
있고 클러스터의 모든 노드에서 전역적으로 접근할 수 없는 스토리지
백엔드의 경우, 파드의 스케줄링 요구 사항에 대한 지식 없이 퍼시스턴트볼륨이
바인딩되거나 프로비저닝된다. 이로 인해 스케줄되지 않은 파드가 발생할 수 있다.
스토리지 클래스에는 스토리지 클래스에 속하는 볼륨을 설명하는 파라미터가
있다. provisioner 에 따라 다른 파라미터를 사용할 수 있다. 예를 들어,
파라미터 type 에 대한 값 io1 과 파라미터 iopsPerGB 는
EBS에만 사용할 수 있다. 파라미터 생략 시 일부 기본값이
사용된다.
스토리지클래스에 대해 최대 512개의 파라미터를 정의할 수 있다.
키와 값을 포함하여 파라미터 오브젝터의 총 길이는 256 KiB를
초과할 수 없다.
type: io1, gp2, sc1, st1. 자세한 내용은
AWS 문서를
본다. 기본값: gp2.
zone (사용 중단(deprecated)): AWS 영역. zone 과 zones 를 지정하지 않으면, 일반적으로
쿠버네티스 클러스터의 노드가 있는 모든 활성화된 영역에 걸쳐 볼륨이
라운드 로빈으로 조정된다. zone 과 zones 파라미터를 동시에 사용해서는 안된다.
zones (사용 중단): 쉼표로 구분된 AWS 영역의 목록. zone 과 zones 를
지정하지 않으면, 일반적으로 쿠버네티스 클러스터의 노드가 있는 모든 활성화된 영역에 걸쳐
볼륨이 라운드 로빈으로 조정된다. zone 과 zones 파라미터를
동시에 사용해서는 안된다.
iopsPerGB: io1 볼륨 전용이다. 1초당 GiB에 대한 I/O 작업 수이다. AWS
볼륨 플러그인은 요청된 볼륨 크기에 곱셈하여 볼륨의 IOPS를
계산하고 이를 20,000 IOPS로 제한한다(AWS에서 지원하는 최대값으로,
AWS 문서를 본다).
여기에는 문자열, 즉 10 이 아닌, "10" 이 필요하다.
fsType: fsType은 쿠버네티스에서 지원된다. 기본값: "ext4".
encrypted: EBS 볼륨의 암호화 여부를 나타낸다.
유효한 값은 "ture" 또는 "false" 이다. 여기에는 문자열,
즉 true 가 아닌, "true" 가 필요하다.
kmsKeyId: 선택 사항. 볼륨을 암호화할 때 사용할 키의 전체 Amazon
리소스 이름이다. 아무것도 제공되지 않지만, encrypted 가 true라면
AWS에 의해 키가 생성된다. 유효한 ARN 값은 AWS 문서를 본다.
zone (사용 중단): GCE 영역. zone 과 zones 를 모두 지정하지 않으면, 쿠버네티스 클러스터의
노드가 있는 모든 활성화된 영역에 걸쳐 볼륨이 라운드 로빈으로
조정된다. zone 과 zones 파라미터를 동시에 사용해서는 안된다.
zones (사용 중단): 쉼표로 구분되는 GCE 영역의 목록. zone 과 zones 를 모두
지정하지 않으면, 쿠버네티스 클러스터의 노드가 있는 모든 활성화된 영역에
걸쳐 볼륨이 라운드 로빈으로 조정된다. zone 과 zones 파라미터를
동시에 사용해서는 안된다.
fstype: ext4 또는 xfs. 기본값: ext4. 정의된 파일시스템 유형은 호스트 운영체제에서 지원되어야 한다.
replication-type: none 또는 regional-pd. 기본값: none.
replication-type 을 none 으로 설정하면 (영역) PD가 프로비전된다.
replication-type 이 regional-pd 로 설정되면,
지역 퍼시스턴트 디스크
가 프로비전된다. 이는 퍼시스턴트볼륨클레임과 스토리지클래스를 소모하는 파드를
생성할 때 지역 퍼시스턴트 디스크는 두개의 영역으로
프로비전되기에 volumeBindingMode: WaitForFirstConsumer 를
설정하는 것을 강력히 권장한다. 하나의 영역은 파드가 스케줄된
영역과 동일하다. 다른 영역은 클러스터에서 사용할 수
있는 영역에서 임의로 선택된다. 디스크 영역은 allowedTopologies 를
사용하면 더 제한할 수 있다.
resturl: 필요에 따라 gluster 볼륨을 프로비전하는 Gluster REST 서비스/Heketi
서비스 url 이다. 일반적인 형식은 IPaddress:Port 이어야 하며 이는 GlusterFS
동적 프로비저너의 필수 파라미터이다. Heketi 서비스가 openshift/kubernetes
설정에서 라우팅이 가능한 서비스로 노출이 되는 경우 이것은 fqdn이 해석할 수 있는
Heketi 서비스 url인 http://heketi-storage-project.cloudapps.mystorage.com 과
유사한 형식을 가질 수 있다.
restauthenabled : REST 서버에 대한 인증을 가능하게 하는 Gluster REST 서비스
인증 부울이다. 이 값이 "true" 이면, restuser 와 restuserkey
또는 secretNamespace + secretName 을 채워야 한다. 이 옵션은
사용 중단이며, restuser, restuserkey, secretName 또는
secretNamespace 중 하나를 지정하면 인증이 활성화된다.
restuser : Gluster REST 서비스/Heketi 사용자로 Gluster Trusted Pool에서
볼륨을 생성할 수 있다.
restuserkey : REST 서버에 대한 인증에 사용될 Gluster REST 서비스/Heketi
사용자의 암호이다. 이 파라미터는 secretNamespace + secretName 을 위해
사용 중단 되었다.
secretNamespace, secretName : Gluster REST 서비스와 통신할 때 사용할
사용자 암호가 포함된 시크릿 인스턴스를 식별한다. 이 파라미터는
선택 사항으로 secretNamespace 와 secretName 을 모두 생략하면
빈 암호가 사용된다. 제공된 시크릿은 "kubernetes.io/glusterfs" 유형이어야
하며, 예를 들어 다음과 같이 생성한다.
clusterid: 630372ccdc720a92c681fb928f27b53f 는 볼륨을 프로비저닝할
때 Heketi가 사용할 클러스터의 ID이다. 또한, 예시와 같이 클러스터
ID 목록이 될 수 있다. 예:
"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397". 이것은
선택적 파라미터이다.
gidMin, gidMax : 스토리지클래스에 대한 GID 범위의 최소값과
최대값이다. 이 범위( gidMin-gidMax )의 고유한 값(GID)은 동적으로
프로비전된 볼륨에 사용된다. 이것은 선택적인 값이다. 지정하지 않으면,
볼륨은 각각 gidMin과 gidMax의 기본값인 2000-2147483647
사이의 값으로 프로비전된다.
volumetype : 볼륨 유형과 파라미터는 이 선택적 값으로 구성할
수 있다. 볼륨 유형을 언급하지 않는 경우, 볼륨 유형을 결정하는 것은
프로비저너의 책임이다.
예를 들어:
레플리카 볼륨: volumetype: replicate:3 여기서 '3'은 레플리카의 수이다.
Disperse/EC 볼륨: volumetype: disperse:4:2 여기서 '4'는 데이터이고 '2'는 중복 횟수이다.
datastore: 또한, 사용자는 스토리지클래스에서 데이터스토어를 지정할 수 있다.
볼륨은 스토리지클래스에 지정된 데이터스토어에 생성되며,
이 경우 VSANDatastore 이다. 이 필드는 선택 사항이다. 데이터스토어를
지정하지 않으면, vSphere 클라우드 공급자를 초기화하는데 사용되는 vSphere
설정 파일에 지정된 데이터스토어에 볼륨이
생성된다.
쿠버네티스 내부 스토리지 정책을 관리한다.
기존 vCenter SPBM 정책을 사용한다.
vSphere 스토리지 관리의 가장 중요한 기능 중 하나는
정책 기반 관리이다. 스토리지 정책 기반 관리(Storage Policy Based Management (SPBM))는
광범위한 데이터 서비스와 스토리지 솔루션에서 단일 통합 컨트롤 플레인을
제공하는 스토리지 정책 프레임워크이다. SPBM을 통해 vSphere 관리자는 용량 계획,
차별화된 서비스 수준과 용량의 헤드룸(headroom) 관리와 같은
선행 스토리지 프로비저닝 문제를
극복할 수 있다.
SPBM 정책은 storagePolicyName 파라미터를 사용하면
스토리지클래스에서 지정할 수 있다.
쿠버네티스 내부의 가상 SAN 정책 지원
Vsphere 인프라스트럭쳐(Vsphere Infrastructure (VI)) 관리자는
동적 볼륨 프로비저닝 중에 사용자 정의 가상 SAN 스토리지
기능을 지정할 수 있다. 이제 동적 볼륨 프로비저닝 중에 스토리지
기능의 형태로 성능 및 가용성과 같은 스토리지 요구 사항을 정의할
수 있다. 스토리지 기능 요구 사항은 가상 SAN 정책으로 변환된
퍼시스턴트 볼륨(가상 디스크)을 생성할 때
가상 SAN 계층으로 푸시된다. 가상 디스크는 가상 SAN 데이터
스토어에 분산되어 요구 사항을 충족시키게 된다.
adminId: 풀에 이미지를 생성할 수 있는 Ceph 클라이언트 ID.
기본값은 "admin".
adminSecretName: adminId 의 시크릿 이름. 이 파라미터는 필수이다.
제공된 시크릿은 "kubernetes.io/rbd" 유형이어야 한다.
adminSecretNamespace: adminSecretName 의 네임스페이스. 기본값은 "default".
pool: Ceph RBD 풀. 기본값은 "rbd".
userId: RBD 이미지를 매핑하는 데 사용하는 Ceph 클라이언트 ID. 기본값은
adminId 와 동일하다.
userSecretName: RDB 이미지를 매핑하기 위한 userId 에 대한 Ceph 시크릿 이름. PVC와
동일한 네임스페이스에 존재해야 한다. 이 파라미터는 필수이다.
제공된 시크릿은 "kubernetes.io/rbd" 유형이어야 하며, 다음의 예시와 같이
생성되어야 한다.
quobyteAPIServer: "http(s)://api-server:7860" 형식의
Quobyte의 API 서버이다.
registry: 볼륨을 마운트하는 데 사용할 Quobyte 레지스트리이다. 레지스트리를
<host>:<port> 의 쌍으로 지정할 수 있으며, 여러 레지스트리를
지정하려면 각 쌍을 쉼표로 구분하면 된다.
예: <host1>:<port>,<host2>:<port>,<host3>:<port>
호스트는 IP 주소이거나 DNS가 작동 중인 경우
DNS 이름을 제공할 수도 있다.
adminSecretNamespace: adminSecretName 의 네임스페이스.
기본값은 "default".
adminSecretName: 시크릿은 API 서버에 대해 인증하기 위한 Quobyte 사용자와 암호에
대한 정보를 담고 있다. 제공된 시크릿은 "kubernetes.io/quobyte"
유형과 user 및 password 키를 가져야 하며, 예를 들면
다음과 같다.
kind: 가능한 값은 shared (기본값), dedicated, 그리고 managed 이다.
kind 가 shared 인 경우, 모든 비관리 디스크는 클러스터와
동일한 리소스 그룹에 있는 몇 개의 공유 스토리지 계정에 생성된다. kind 가
dedicated 인 경우, 클러스터와 동일한 리소스 그룹에서 새로운
비관리 디스크에 대해 새로운 전용 스토리지 계정이 생성된다. kind 가
managed 인 경우, 모든 관리 디스크는 클러스터와 동일한 리소스
그룹에 생성된다.
resourceGroup: Azure 디스크를 만들 리소스 그룹을 지정한다.
기존에 있는 리소스 그룹 이름이어야 한다. 지정되지 않는 경우, 디스크는
현재 쿠버네티스 클러스터와 동일한 리소스 그룹에 배치된다.
프리미엄 VM은 표준 LRS(Standard_LRS)와 프리미엄 LRS(Premium_LRS) 디스크를 모두 연결할 수 있는 반면에,
표준 VM은 표준 LRS(Standard_LRS) 디스크만 연결할 수 있다.
관리되는 VM은 관리되는 디스크만 연결할 수 있고,
비관리 VM은 비관리 디스크만 연결할 수 있다.
storageAccount: Azure 스토리지 계정 이름. 기본값은 없음. 스토리지 계정이
제공되지 않으면, 리소스 그룹과 관련된 모든 스토리지 계정이
검색되어 skuName 과 location 이 일치하는 것을 찾는다. 스토리지 계정이
제공되면, 클러스터와 동일한 리소스 그룹에 있어야
하며 skuName 과 location 은 무시된다.
secretNamespace: Azure 스토리지 계정 이름과 키가 포함된 시크릿
네임스페이스. 기본값은 파드와 동일하다.
secretName: Azure 스토리지 계정 이름과 키가 포함된 시크릿 이름.
기본값은 azure-storage-account-<accountName>-secret
readOnly: 스토리지가 읽기 전용으로 마운트되어야 하는지 여부를 나타내는 플래그.
읽기/쓰기 마운트를 의미하는 기본값은 false. 이 설정은
볼륨마운트(VolumeMounts)의 ReadOnly 설정에도 영향을 준다.
스토리지 프로비저닝 중에 마운트 자격증명에 대해 secretName
이라는 시크릿이 생성된다. 클러스터에
RBAC과
컨트롤러의 롤(role)들을
모두 활성화한 경우, clusterrole system:controller:persistent-volume-binder
에 대한 secret 리소스에 create 권한을 추가한다.
다중 테넌시 컨텍스트에서 secretNamespace 의 값을 명시적으로 설정하는
것을 권장하며, 그렇지 않으면 다른 사용자가 스토리지 계정 자격증명을
읽을 수 있기 때문이다.
repl: 레플리케이션 팩터 1..3 (기본값: 1)의 형태로 제공될
동기 레플리카의 수. 여기에는 문자열,
즉 0 이 아닌, "0" 이 필요하다.
priority_io: 볼륨이 고성능 또는 우선 순위가 낮은 스토리지에서
생성될 것인지를 결정한다 high/medium/low (기본값: low).
snap_interval: 스냅샷을 트리거할 때의 시각/시간 간격(분).
스냅샷은 이전 스냅샷과의 차이에 따라 증분되며, 0은 스냅을
비활성화 한다(기본값: 0). 여기에는 문자열,
즉 70 이 아닌, "70" 이 필요하다.
aggregation_level: 볼륨이 분배될 청크 수를 지정하며, 0은 집계되지 않은
볼륨을 나타낸다(기본값: 0). 여기에는 문자열,
즉 0 이 아닌, "0" 이 필요하다.
ephemeral: 마운트 해제 후 볼륨을 정리해야 하는지 혹은 지속적이어야
하는지를 지정한다. emptyDir 에 대한 유스케이스는 이 값을 true로
설정할 수 있으며, persistent volumes 에 대한 유스케이스인
카산드라와 같은 데이터베이스는 false로 설정해야 한다. true/false (기본값 false)
여기에는 문자열, 즉 true 가 아닌, "true" 가 필요하다.
pool: 볼륨을 프로비전할 StorageOS 분산 용량
풀의 이름. 지정되지 않은 경우 일반적으로 존재하는 default 풀을 사용한다.
description: 동적으로 생성된 볼륨에 할당할 설명.
모든 볼륨 설명은 스토리지 클래스에 대해 동일하지만, 서로 다른
유스케이스에 대한 설명을 허용하기 위해 다른 스토리지 클래스를 사용할 수 있다.
기본값은 Kubernetes volume.
fsType: 요청할 기본 파일 시스템 유형. StorageOS 내의 사용자
정의 규칙이 이 값을 무시할 수 있다. 기본 값은 ext4.
adminSecretNamespace: API 구성 시크릿이 있는 네임스페이스.
adminSecretName 이 설정된 경우 필수이다.
adminSecretName: StorageOS API 자격증명을 얻는 데 사용할 시크릿의 이름.
지정하지 않으면 기본값이 시도된다.
StorageOS 쿠버네티스 볼륨 플러그인은 시크릿 오브젝트를 사용해서 StorageOS API에
접근하기 위한 엔드포인트와 자격증명을 지정할 수 있다. 이것은 기본값이
변경된 경우에만 필요하다.
시크릿은 다음의 명령과 같이 kubernetes.io/storageos 유형으로
만들어야 한다.
로컬 볼륨은 현재 동적 프로비저닝을 지원하지 않지만, 파드 스케줄링까지
볼륨 바인딩을 지연시키기 위해서는 스토리지클래스가 여전히 생성되어야 한다. 이것은
WaitForFirstConsumer 볼륨 바인딩 모드에 의해 지정된다.
볼륨 바인딩을 지연시키면 스케줄러가 퍼시스턴트볼륨클레임에
적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링
제약 조건을 고려할 수 있다.
3.6.7 - 동적 볼륨 프로비저닝
동적 볼륨 프로비저닝을 통해 온-디맨드 방식으로 스토리지 볼륨을 생성할 수 있다.
동적 프로비저닝이 없으면 클러스터 관리자는 클라우드 또는 스토리지
공급자에게 수동으로 요청해서 새 스토리지 볼륨을 생성한 다음, 쿠버네티스에
표시하기 위해 PersistentVolume 오브젝트를
생성해야 한다. 동적 프로비저닝 기능을 사용하면 클러스터 관리자가
스토리지를 사전 프로비저닝 할 필요가 없다. 대신 사용자가
스토리지를 요청하면 자동으로 프로비저닝 한다.
배경
동적 볼륨 프로비저닝의 구현은 storage.k8s.io API 그룹의 StorageClass
API 오브젝트를 기반으로 한다. 클러스터 관리자는 볼륨을 프로비전하는
볼륨 플러그인 (프로비저너라고도 알려짐)과 프로비저닝시에 프로비저너에게
전달할 파라미터 집합을 지정하는 StorageClass
오브젝트를 필요한 만큼 정의할 수 있다.
클러스터 관리자는 클러스터 내에서 사용자 정의 파라미터 집합을
사용해서 여러 가지 유형의 스토리지 (같거나 다른 스토리지 시스템들)를
정의하고 노출시킬 수 있다. 또한 이 디자인을 통해 최종 사용자는
스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만,
여전히 여러 스토리지 옵션들을 선택할 수 있다.
동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 스토리지클래스(StorageClass)
오브젝트를 사전 생성해야 한다.
스토리지클래스 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와
해당 프로비저너에게 전달할 파라미터를 정의한다.
스토리지클래스 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
다음 매니페스트는 표준 디스크와 같은 퍼시스턴트 디스크를 프로비전하는
스토리지 클래스 "slow"를 만든다.
사용자는 PersistentVolumeClaim 에 스토리지 클래스를 포함시켜 동적으로 프로비전된
스토리지를 요청한다. 쿠버네티스 v1.6 이전에는 volume.beta.kubernetes.io/storage-class
어노테이션을 통해 수행되었다. 그러나 이 어노테이션은
v1.9부터는 더 이상 사용하지 않는다. 사용자는 이제 PersistentVolumeClaim 오브젝트의
storageClassName 필드를 사용해야 한다. 이 필드의 값은
관리자가 구성한 StorageClass 의 이름과
일치해야 한다. (아래를 참고)
예를 들어 "fast" 스토리지 클래스를 선택하려면 다음과
같은 PersistentVolumeClaim 을 생성한다.
관리자는 storageclass.kubernetes.io/is-default-class 어노테이션을
추가해서 특정 StorageClass 를 기본으로 표시할 수 있다.
기본 StorageClass 가 클러스터에 존재하고 사용자가
storageClassName 를 지정하지 않은 PersistentVolumeClaim 을
작성하면, DefaultStorageClass 어드미션 컨트롤러가 디폴트
스토리지 클래스를 가리키는 storageClassName 필드를 자동으로 추가한다.
클러스터에는 최대 하나의 default 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우
storageClassName 을 명시적으로 지정하지 않은 PersistentVolumeClaim 을
생성할 수 없다.
토폴로지 인식
다중 영역 클러스터에서 파드는 한 지역 내
여러 영역에 걸쳐 분산될 수 있다. 파드가 예약된 영역에서 단일 영역 스토리지 백엔드를
프로비전해야 한다. 볼륨 바인딩 모드를
설정해서 수행할 수 있다.
3.6.8 - 노드 별 볼륨 한도
이 페이지는 다양한 클라우드 공급자들이 제공하는 노드에 연결할 수 있는
최대 볼륨 수를 설명한다.
Google, Amazon 그리고 Microsoft와 같은 클라우드 공급자는 일반적으로 노드에
연결할 수 있는 볼륨 수에 제한이 있다. 쿠버네티스가 이러한 제한을
준수하는 것은 중요하다. 그렇지 않으면, 노드에서 예약된 파드가 볼륨이
연결될 때까지 멈추고 기다릴 수 있다.
CSI 드라이버로 마이그레이션된 인-트리 플러그인으로 관리되는 볼륨의 경우, 최대 볼륨 수는 CSI 드라이버가 보고한 개수이다.
3.7 - 구성
쿠버네티스가 파드 구성을 위해 제공하는 리소스
3.7.1 - 구성 모범 사례
이 문서는 사용자 가이드, 시작하기 문서 및 예제들에 걸쳐 소개된 구성 모범 사례를 강조하고 통합한다.
이 문서는 지속적으로 변경 가능하다. 이 목록에 없지만 다른 사람들에게 유용할 것 같은 무엇인가를 생각하고 있다면, 새로운 이슈를 생성하거나 풀 리퀘스트를 제출하는 것을 망설이지 말기를 바란다.
일반적인 구성 팁
구성을 정의할 때, 안정된 최신 API 버전을 명시한다.
구성 파일들은 클러스터에 적용되기 전에 버전 컨트롤에 저장되어 있어야 한다. 이는 만약 필요하다면 구성의 변경 사항을 빠르게 되돌릴 수 있도록 해준다. 이는 또한 클러스터의 재-생성과 복원을 도와준다.
JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.
의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 guestbook-all-in-one.yaml 파일을 참고한다.
많은 kubectl 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 kubectl apply를 호출할 수 있다.
불필요하게 기본 값을 명시하지 않는다. 간단하고 최소한의 설정은 에러를 덜 발생시킨다.
더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다.
"단독(Naked)" 파드 vs 레플리카셋(ReplicaSet), 디플로이먼트(Deployment), 그리고 잡(Job)
가능하다면 단독 파드(즉, 레플리카셋이나 디플로이먼트에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
명백하게 restartPolicy: Never를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카셋을 생성하고, 파드를 교체하는 전략(롤링 업데이트와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. 잡 또한 적절할 수 있다.
서비스
서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 서비스를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, foo 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
이는 순서를 정하는 일이 요구됨을 암시한다 - 파드가 접근하기를 원하는 어떠한 서비스는 파드 스스로가 생성되기 전에 미리 생성되어 있어야 하며, 그렇지 않으면 환경 변수가 설정되지 않을 것이다. DNS는 이러한 제한을 가지고 있지 않다.
선택적인(그렇지만 매우 권장되는) 클러스터 애드온은 DNS 서버이다.
DNS 서버는 새로운 서비스를 위한 쿠버네티스 API를 Watch하며, 각 서비스를 위한 DNS 레코드 셋을 생성한다. 만약 DNS가 클러스터에 걸쳐 활성화되어 있다면, 모든 파드는 서비스의 이름을 자동으로 해석할 수 있어야 한다.
반드시 필요한 것이 아니라면 파드에 hostPort 를 명시하지 않는다. <hostIP, hostPort, protocol> 조합은 유일해야 하기 때문에, hostPort로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 hostIP와 protocol을 뚜렷히 명시하지 않으면, 쿠버네티스는 hostIP의 기본 값으로 0.0.0.0를, protocol의 기본 값으로 TCP를 사용한다.
만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, hostPort에 의존하기 전에 NodePort 서비스를 사용하는 것을 고려할 수 있다.
hostPort와 같은 이유로, hostNetwork를 사용하는 것을 피한다.
kube-proxy 로드 밸런싱이 필요하지 않을 때, 서비스 발견을 위해 헤드리스 서비스(ClusterIP의 값을 None으로 가지는)를 사용한다.
레이블 사용하기
{ app: myapp, tier: frontend, phase: test, deployment: v3 }처럼 애플리케이션이나 디플로이먼트의 속성에 대한 의미 를 식별하는 레이블을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 tier: frontend 파드를 선택하거나, app: myapp의 모든 phase: test 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 방명록 앱을 참고한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, 디플로이먼트를 사용한다.
오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 적용될 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
일반적인 활용 사례인 경우 쿠버네티스 공통 레이블을 사용한다. 이 표준화된 레이블은 kubectl 및 대시보드와 같은 도구들이 상호 운용이 가능한 방식으로 동작할 수 있도록 메타데이터를 향상시킨다.
디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, kubectl label를 사용할 수 있다.
imagePullPolicy: IfNotPresent: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다.
imagePullPolicy: Always: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다.
imagePullPolicy가 생략되어 있고, 이미지 태그가 :latest 이거나 생략되어 있다면 imagePullPolicy는 자동으로 Always가 적용된다. 태그 값을 변경하더라도 이 값은 IfNotPresent로 업데이트 되지 않는다.
imagePullPolicy가 생략되어 있고, 이미지 태그가 존재하지만 :latest가 아니라면 imagePullPolicy는 자동으로 IfNotPresent가 적용된다. 태그가 나중에 제거되거나 :latest로 변경되더라도 Always로 업데이트 되지 않는다.
imagePullPolicy: Never: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다.
참고: 컨테이너가 항상 같은 버전의 이미지를 사용하도록 하기 위해, <이미지 이름>:<태그> 를 <이미지 이름>@<다이제스트> (예시 image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2)로 변경해서 이미지의 다이제스트를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다.
참고: 운영 환경에서 컨테이너를 생성할 때 :latest 태그의 사용을 피하는 것이 좋은데, 이는 어떠한 버전의 이미지가 실행 중인지 추적하기가 어렵고, 적절히 롤백하기가 더 어려워지기 때문이다.
참고: 레지스트리가 안정적으로 동작하는 상황에서는, imagePullPolicy: Always로 설정되어 있더라도 기반 이미지 관리 도구의 캐싱 정책을 통해 이미지 풀(pull) 작업의 효율성을 높일 수 있다. 예를 들어, 도커를 사용하는 경우 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
kubectl 사용하기
kubectl apply -f <디렉터리>를 사용한다. 이 명령어는 <디렉터리> 내부의 모든 .yaml, .yml, 그리고 .json 쿠버네티스 구성 파일을 찾아 apply에 전달한다.
단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 kubectl create deployment 와 kubectl expose 를 사용한다. 클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용에서 예시를 확인할 수 있다.
3.7.2 - 컨피그맵(ConfigMap)
컨피그맵은 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다.
파드는
볼륨에서
환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다.
컨피그맵을 사용하면 컨테이너 이미지에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다.
주의: 컨피그맵은 보안 또는 암호화를 제공하지 않는다.
저장하려는 데이터가 기밀인 경우, 컨피그맵
대신 시크릿(Secret) 또는 추가(써드파티) 도구를
사용하여 데이터를 비공개로 유지하자.
사용 동기
애플리케이션 코드와 별도로 구성 데이터를 설정하려면 컨피그맵을 사용하자.
예를 들어, 자신의 컴퓨터(개발용)와 클라우드(실제 트래픽 처리)에서
실행할 수 있는 애플리케이션을 개발한다고 가정해보자.
DATABASE_HOST 라는 환경 변수를 찾기 위해 코드를 작성한다.
로컬에서는 해당 변수를 localhost 로 설정한다. 클라우드에서는, 데이터베이스
컴포넌트를 클러스터에 노출하는 쿠버네티스 서비스를
참조하도록 설정한다.
이를 통해 클라우드에서 실행 중인 컨테이너 이미지를 가져와
필요한 경우 정확히 동일한 코드를 로컬에서 디버깅할 수 있다.
컨피그맵은 많은 양의 데이터를 보유하도록 설계되지 않았다. 컨피그맵에 저장된
데이터는 1MiB를 초과할 수 없다. 이 제한보다 큰 설정을
저장해야 하는 경우, 볼륨을 마운트하는 것을 고려하거나 별도의
데이터베이스 또는 파일 서비스를 사용할 수 있다.
컨피그맵 오브젝트
컨피그맵은 다른 오브젝트가 사용할 구성을 저장할 수 있는
API 오브젝트이다.
spec 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 data 및 binaryData
필드가 있다. 이러한 필드는 키-값 쌍을 값으로 허용한다. data 필드와
binaryData 는 모두 선택 사항이다. data 필드는
UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 binaryData 필드는 바이너리
데이터를 base64로 인코딩된 문자열로 포함하도록 설계되었다.
data 또는 binaryData 필드 아래의 각 키는
영숫자 문자, -, _ 또는 . 으로 구성되어야 한다. data 에 저장된 키는
binaryData 필드의 키와 겹치지 않아야 한다.
v1.19부터 컨피그맵 정의에 immutable 필드를 추가하여
변경할 수 없는 컨피그맵을 만들 수 있다.
컨피그맵과 파드
컨피그맵을 참조하는 파드 spec 을 작성하고 컨피그맵의 데이터를
기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은
동일한 네임스페이스에 있어야 한다.
다음은 단일 값을 가진 키와,
값이 구성 형식의 일부처럼 보이는 키를 가진 컨피그맵의
예시이다.
apiVersion:v1kind:ConfigMapmetadata:name:game-demodata:# 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨player_initial_lives:"3"ui_properties_file_name:"user-interface.properties"# 파일과 비슷한 키game.properties:| enemy.types=aliens,monsters
player.maximum-lives=5user-interface.properties:| color.good=purple
color.bad=yellow
allow.textmode=true
컨피그맵을 사용하여 파드 내부에 컨테이너를 구성할 수 있는
네 가지 방법이 있다.
컨테이너 커맨드와 인수 내에서
컨테이너에 대한 환경 변수
애플리케이션이 읽을 수 있도록 읽기 전용 볼륨에 파일 추가
쿠버네티스 API를 사용하여 컨피그맵을 읽는 파드 내에서 실행할 코드 작성
이러한 방법들은 소비되는 데이터를 모델링하는
방식에 따라 다르게 쓰인다.
처음 세 가지 방법의 경우,
kubelet은 파드의 컨테이너를 시작할 때
컨피그맵의 데이터를 사용한다.
네 번째 방법은 컨피그맵과 데이터를 읽기 위해 코드를 작성해야 한다는 것을 의미한다.
그러나, 쿠버네티스 API를 직접 사용하기 때문에, 애플리케이션은
컨피그맵이 변경될 때마다 업데이트를 받기 위해 구독할 수 있고, 업데이트가
있으면 반응한다. 쿠버네티스 API에 직접 접근하면, 이
기술을 사용하여 다른 네임스페이스의 컨피그맵에 접근할 수도 있다.
다음은 game-demo 의 값을 사용하여 파드를 구성하는 파드 예시이다.
apiVersion:v1kind:Podmetadata:name:configmap-demo-podspec:containers:- name:demoimage:alpinecommand:["sleep","3600"]env:# 환경 변수 정의- name:PLAYER_INITIAL_LIVES# 참고로 여기서는 컨피그맵의 키 이름과# 대소문자가 다르다.valueFrom:configMapKeyRef:name:game-demo # 이 값의 컨피그맵.key:player_initial_lives# 가져올 키.- name:UI_PROPERTIES_FILE_NAMEvalueFrom:configMapKeyRef:name:game-demokey:ui_properties_file_namevolumeMounts:- name:configmountPath:"/config"readOnly:truevolumes:# 파드 레벨에서 볼륨을 설정한 다음, 해당 파드 내의 컨테이너에 마운트한다.- name:configconfigMap:# 마운트하려는 컨피그맵의 이름을 제공한다.name:game-demo# 컨피그맵에서 파일로 생성할 키 배열items:- key:"game.properties"path:"game.properties"- key:"user-interface.properties"path:"user-interface.properties"
컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을
구분하지 않는다.
더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다.
이 예제에서, 볼륨을 정의하고 demo 컨테이너에
/config 로 마운트하면 컨피그맵에 4개의 키가 있더라도
/config/game.properties 와 /config/user-interface.properties
2개의 파일이 생성된다. 이것은 파드 정의가
volume 섹션에서 items 배열을 지정하기 때문이다.
items 배열을 완전히 생략하면, 컨피그맵의 모든 키가
키와 이름이 같은 파일이 되고, 4개의 파일을 얻게 된다.
컨피그맵 사용하기
컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로
노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의
파드에서 실행되는 컨테이너에 대한 설정을 구성하는 것이다. 컨피그맵을
별도로 사용할 수도 있다.
컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을
참조할 수 있다.
파드 정의를 수정해서 .spec.volumes[] 아래에 볼륨을 추가한다. 볼륨 이름은
원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 .spec.volumes[].configMap.name
필드를 설정한다.
컨피그맵이 필요한 각 컨테이너에 .spec.containers[].volumeMounts[] 를
추가한다. .spec.containers[].volumeMounts[].readOnly = true 를 설정하고
컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로
.spec.containers[].volumeMounts[].mountPath 를 지정한다.
프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을
수정한다. 컨피그맵의 data 맵 각 키는 mountPath 아래의
파일 이름이 된다.
파드에 여러 컨테이너가 있는 경우 각 컨테이너에는 자체 volumeMounts 블록이 필요하지만,
컨피그맵은 각 컨피그맵 당 하나의 .spec.volumes 만 필요하다.
마운트된 컨피그맵이 자동으로 업데이트
현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다.
kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다.
그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
캐시 유형은 KubeletConfiguration 구조체의
ConfigMapAndSecretChangeDetectionStrategy 필드를 사용해서 구성할 수 있다.
컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
모든 요청을 리디렉션할 수 있다.
따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의
총 지연시간은 kubelet 동기화 기간 + 캐시 전파 지연만큼 길 수 있다. 여기서 캐시
전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파
지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).
환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
변경할 수 없는(immutable) 컨피그맵
FEATURE STATE:Kubernetes v1.19 [beta]
쿠버네티스 베타 기능인 변경할 수 없는 시크릿과 컨피그맵 은 개별 시크릿과
컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게
사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우
데이터 변경을 방지하면 다음과 같은 이점이 있다.
애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써
클러스터의 성능을 향상시킴
이 기능은 ImmutableEphemeralVolumes기능 게이트에 의해 제어된다.
immutable 필드를 true 로 설정하여 변경할 수 없는 컨피그맵을 생성할 수 있다.
다음은 예시이다.
컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
data 또는 binaryData 필드 내용을 변경할 수 없다. 컨피그맵만
삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을
유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다.
쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
민감한 정보를 저장하고 관리할 수 있다. 기밀 정보를 시크릿에 저장하는 것이
파드(Pod) 정의나
컨테이너 이미지
내에 그대로 두는 것보다 안전하고 유연하다.
자세한 내용은 시크릿 디자인 문서를 참고한다.
시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를
포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 파드
명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
일부 시크릿을 만들 수 있다.
주의:
쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
시크릿 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
사용자는 시크릿을 위한 파일을 구성할 때 data 및 (또는) stringData 필드를
명시할 수 있다. 해당 data 와 stringData 필드는 선택적으로 명시할 수 있다.
data 필드의 모든 키(key)에 해당하는 값(value)은 base64로 인코딩된 문자열이어야 한다.
만약 사용자에게 base64로의 문자열 변환이 적합하지 않다면,
임의의 문자열을 값으로 받는 stringData 필드를 대신 사용할 수 있다.
data 및 stringData의 키는 영숫자 문자,
-, _, 또는 . 으로 구성되어야 한다. stringData 필드의 모든 키-값 쌍은 의도적으로
data 필드로 합쳐진다. 만약 키가 data 와 stringData 필드 모두에 정의되어
있으면, stringData 필드에 지정된 값이
우선적으로 사용된다.
시크릿 타입
시크릿을 생성할 때, Secret
리소스의 type 필드를 사용하거나, (활용 가능하다면) kubectl 의
유사한 특정 커맨드라인 플래그를 사용하여 시크릿의 타입을 명시할 수 있다.
시크릿 타입은 시크릿 데이터의 프로그래믹 처리를 촉진시키기 위해 사용된다.
쿠버네티스는 일반적인 사용 시나리오를 위해 몇 가지 빌트인 타입을 제공한다.
이 타입은 쿠버네티스가 부과하여 수행되는 검증 및 제약에
따라 달라진다.
빌트인 타입
사용처
Opaque
임의의 사용자 정의 데이터
kubernetes.io/service-account-token
서비스 어카운트 토큰
kubernetes.io/dockercfg
직렬화 된(serialized) ~/.dockercfg 파일
kubernetes.io/dockerconfigjson
직렬화 된 ~/.docker/config.json 파일
kubernetes.io/basic-auth
기본 인증을 위한 자격 증명(credential)
kubernetes.io/ssh-auth
SSH를 위한 자격 증명
kubernetes.io/tls
TLS 클라이언트나 서버를 위한 데이터
bootstrap.kubernetes.io/token
부트스트랩 토큰 데이터
사용자는 시크릿 오브젝트의 type 값에 비어 있지 않은 문자열을 할당하여 자신만의 시크릿
타입을 정의하고 사용할 수 있다. 비어 있는 문자열은 Opaque 타입으로 인식된다.
쿠버네티스는 타입 명칭에 제약을 부과하지는 않는다. 그러나 만약
빌트인 타입 중 하나를 사용한다면, 해당 타입에 정의된 모든 요구 사항을
만족시켜야 한다.
불투명(Opaque) 시크릿
Opaque 은 시크릿 구성 파일에서 누락된 경우의 기본 시크릿 타입이다.
kubectl 을 사용하여 시크릿을 생성할 때 Opaque 시크릿 타입을 나타내기
위해서는 generic 하위 커맨드를 사용할 것이다. 예를 들어, 다음 커맨드는
타입 Opaque 의 비어 있는 시크릿을 생성한다.
kubectl create secret generic empty-secret
kubectl get secret empty-secret
출력은 다음과 같다.
NAME TYPE DATA AGE
empty-secret Opaque 0 2m6s
해당 DATA 열은 시크릿에 저장된 데이터 아이템의 수를 보여준다.
이 경우, 0 은 비어 있는 시크릿을 하나 생성하였다는 것을 의미한다.
서비스 어카운트 토큰 시크릿
kubernetes.io/service-account-token 시크릿 타입은 서비스 어카운트를 확인하는 토큰을 저장하기 위해서 사용한다. 이 시크릿 타입을 사용할 때는,
kubernetes.io/service-account.name 어노테이션이 존재하는 서비스
어카운트 이름으로 설정되도록 해야 한다. 쿠버네티스 컨트롤러는
kubernetes.io/service-account.uid 및 실제 토큰
콘텐츠로 설정된 data 필드의 token 키와 같은,
몇 가지 다른 필드들을 채운다.
다음은 서비스 어카운트 토큰 시크릿의 구성 예시이다.
apiVersion:v1kind:Secretmetadata:name:secret-sa-sampleannotations:kubernetes.io/service-account.name:"sa-name"type:kubernetes.io/service-account-tokendata:# 사용자는 불투명 시크릿을 사용하므로 추가적인 키 값 쌍을 포함할 수 있다.extra:YmFyCg==
Pod 를 생성할 때, 쿠버네티스는 자동으로 서비스 어카운트 시크릿을
생성하고 자동으로 파드가 해당 시크릿을 사용하도록 수정한다. 해당 서비스
어카운트 토큰 시크릿은 API 접속을 위한 자격 증명을 포함한다.
이러한 API 자격 증명의 자동 생성과 사용은 원하는 경우 해제하거나
기각할 수 있다. 그러나 만약 사용자가 API 서버에 안전하게 접근하는 것만
필요하다면, 이것이 권장되는 워크플로우이다.
서비스 어카운트 문서를 보면
서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다.
또한 파드에서 서비스 어카운트를 참조하는 방법을
Pod의
automountServiceAccountToken 필드와 serviceAccountName
필드를 통해 확인할 수 있다.
도커 컨피그 시크릿
이미지에 대한 도커 레지스트리 접속 자격 증명을 저장하기 위한
시크릿을 생성하기 위해서 다음의 type 값 중 하나를 사용할 수 있다.
kubernetes.io/dockercfg
kubernetes.io/dockerconfigjson
kubernetes.io/dockercfg 는 직렬화 된 도커 커맨드라인 구성을
위한 기존(legacy) 포맷 ~/.dockercfg 를 저장하기 위해 할당된 타입이다.
시크릿 타입을 사용할 때는, data 필드가 base64 포맷으로
인코딩된 ~/.dockercfg 파일의 콘텐츠를 값으로 가지는 .dockercfg 키를 포함하고 있는지
확실히 확인해야 한다.
kubernetes.io/dockerconfigjson 타입은 ~/.dockercfg 의
새로운 포맷인 ~/.docker/config.json 파일과 동일한 포맷 법칙을
따르는 직렬화 된 JSON의 저장을 위해 디자인되었다.
이 시크릿 타입을 사용할 때는, 시크릿 오브젝트의 data 필드가 .dockerconfigjson 키를
꼭 포함해야 한다. ~/.docker/config.json 파일을 위한 콘텐츠는
base64로 인코딩된 문자열으로 제공되어야 한다.
이 기본 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다.
사용자는 기본 인증에서 사용되는 자격 증명을 위한 Opaque 를 생성할 수도 있다.
그러나, 빌트인 시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고,
API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지
검증도 한다.
SSH 인증 시크릿
이 빌트인 타입 kubernetes.io/ssh-auth 는 SSH 인증에 사용되는 데이터를
저장하기 위해서 제공된다. 이 시크릿 타입을 사용할 때는 ssh-privatekey
키-값 쌍을 사용할 SSH 자격 증명으로 data (또는 stringData)
필드에 명시해야 할 것이다.
다음 YAML은 SSH 인증 시크릿의 구성 예시이다.
apiVersion:v1kind:Secretmetadata:name:secret-ssh-authtype:kubernetes.io/ssh-authdata:# 본 예시를 위해 축약된 데이터임ssh-privatekey:|MIIEpQIBAAKCAQEAulqb/Y ...
SSH 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다.
사용자는 SSH 인증에서 사용되는 자격 증명을 위한 Opaque 를 생성할 수도 있다.
그러나, 빌트인 시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고,
API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지
검증도 한다.
주의: SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버 간에 신뢰할 수 있는 통신을
설정하지 않는다. 컨피그맵(ConfigMap)에 추가된 known_hosts 파일과 같은
"중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는
2차 수단이 필요하다.
TLS 시크릿
쿠버네티스는 보통 TLS를 위해 사용되는 인증서와 관련된 키를 저장하기 위해서
빌트인 시크릿 타입 kubernetes.io/tls 를 제공한다.
이 데이터는 인그레스 리소스의 TLS 종료에 주로 사용되지만, 다른
리소스나 워크로드에 의해 직접적으로 사용될 수도 있다.
이 타입의 시크릿을 사용할 때는 tls.key 와 tls.crt 키가 시크릿 구성의
data (또는 stringData) 필드에서 제공되어야 한다. 그러나, API
서버가 각 키에 대한 값이 유효한지 실제로 검증하지는 않는다.
다음 YAML은 TLS 시크릿을 위한 구성 예시를 포함한다.
apiVersion:v1kind:Secretmetadata:name:secret-tlstype:kubernetes.io/tlsdata:# 본 예시를 위해 축약된 데이터임tls.crt:|MIIC2DCCAcCgAwIBAgIBATANBgkqh ...tls.key:|MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
TLS 시크릿 타입은 사용자 편의만을 위해서 제공된다. 사용자는 TLS 서버 및/또는
클라이언트를 위해 사용되는 자격 증명을 위한 Opaque 를 생성할 수도 있다. 그러나, 빌트인
시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고,
API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지 검증도 한다.
kubectl 를 사용하여 TLS 시크릿을 생성할 때, tls 하위 커맨드를
다음 예시와 같이 사용할 수 있다.
공개/개인 키 쌍은 사전에 존재해야 한다. --cert 를 위한 공개 키 인증서는
.PEM 으로 인코딩(Base64로 인코딩된 DER 포맷)되어야 하며, --key 를 위해 주어진
개인 키에 맞아야 한다.
개인 키는 일반적으로 PEM 개인 키 포맷이라고 하는,
암호화되지 않은 형태(unencrypted)이어야 한다. 두 가지 방식 모두에 대해서, PEM의
시작과 끝 라인(예를 들면, 인증서의 --------BEGIN CERTIFICATE----- 및 -------END CERTIFICATE----)
은 포함되면 안 된다.
부트스트랩 토큰 시크릿
부트스트랩 토큰 시크릿은 시크릿 type 을 bootstrap.kubernetes.io/token 으로
명확하게 지정하면 생성할 수 있다. 이 타입의 시크릿은 노드 부트스트랩 과정 중에 사용되는
토큰을 위해 디자인되었다. 이것은 잘 알려진 컨피그맵에 서명하는 데 사용되는
토큰을 저장한다.
부트스트랩 토큰 시크릿은 보통 kube-system 네임스페이스에 생성되며
<token-id> 가 해당 토큰 ID의 6개 문자의 문자열으로 구성된 bootstrap-token-<token-id> 형태로
이름이 지정된다.
description: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
문자열. 선택 사항.
expiration: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를
사용하는 절대 UTC 시간. 선택 사항.
usage-bootstrap-<usage>: 부트스트랩 토큰의 추가적인 사용처를 나타내는
불리언(boolean) 플래그.
auth-extra-groups: system:bootstrappers 그룹에 추가로 인증될
쉼표로 구분된 그룹 이름 목록.
위의 YAML은 모두 base64로 인코딩된 문자열 값이므로 혼란스러워 보일
수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿을 생성할 수 있다.
apiVersion:v1kind:Secretmetadata:# 시크릿 이름이 어떻게 지정되었는지 확인name:bootstrap-token-5emitj# 부트스트랩 토큰 시크릿은 일반적으로 kube-system 네임스페이스에 포함namespace:kube-systemtype:bootstrap.kubernetes.io/tokenstringData:auth-extra-groups:"system:bootstrappers:kubeadm:default-node-token"expiration:"2020-09-13T04:39:10Z"# 이 토큰 ID는 이름에 사용됨token-id:"5emitj"token-secret:"kq4gihvszzgn1p0r"# 이 토큰은 인증을 위해서 사용될 수 있음usage-bootstrap-authentication:"true"# 또한 서명(signing)에도 사용될 수 있음usage-bootstrap-signing:"true"
이렇게 하면 기본으로 설정된 에디터가 열리고 data 필드에 base64로 인코딩된 시크릿 값을 업데이트할 수 있다.
# 아래 오브젝트를 수정한다. '#'로 시작하는 줄은 무시되고,# 빈 파일은 편집이 취소될 것이다. 이 파일을 저장하는 도중에 오류가 발생하면# 관련 오류와 함께 다시 열린다.#apiVersion:v1data:username:YWRtaW4=password:MWYyZDFlMmU2N2Rmkind:Secretmetadata:annotations:kubectl.kubernetes.io/last-applied-configuration:{... }creationTimestamp:2016-01-22T18:41:56Zname:mysecretnamespace:defaultresourceVersion:"164619"uid:cfee02d6-c137-11e5-8d73-42010af00002type:Opaque
시크릿 사용하기
시크릿은 데이터 볼륨으로 마운트되거나 파드의 컨테이너에서 사용할
환경 변수로
노출될 수 있다. 또한, 시크릿은 파드에 직접 노출되지 않고,
시스템의 다른 부분에서도 사용할 수 있다. 예를 들어, 시크릿은
시스템의 다른 부분이 사용자를 대신해서 외부 시스템과 상호 작용하는 데 사용해야 하는
자격 증명을 보유할 수 있다.
시크릿을 파드의 파일로 사용하기
파드의 볼륨에서 시크릿을 사용하려면 다음과 같이 한다.
시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다.
.spec.volumes[]. 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고, 시크릿 오브젝트의 이름과 동일한 .spec.volumes[].secret.secretName 필드를 생성한다.
시크릿이 필요한 각 컨테이너에 .spec.containers[].volumeMounts[] 를 추가한다. 시크릿을 표시하려는 사용되지 않은 디렉터리 이름에 .spec.containers[].volumeMounts[].readOnly = true 와 .spec.containers[].volumeMounts[].mountPath 를 지정한다.
프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 data 맵의 각 키는 mountPath 아래의 파일명이 된다.
username 시크릿은 /etc/foo/username 대신 /etc/foo/my-group/my-username 아래의 파일에 저장된다.
password 시크릿은 투영되지 않는다.
.spec.volumes[].secret.items 를 사용하면, items 에 지정된 키만 투영된다.
시크릿의 모든 키를 사용하려면, 모든 키가 items 필드에 나열되어야 한다.
나열된 모든 키는 해당 시크릿에 존재해야 한다. 그렇지 않으면, 볼륨이 생성되지 않는다.
시크릿 파일 퍼미션
단일 시크릿 키에 대한 파일 접근 퍼미션 비트를 설정할 수 있다.
만약 사용자가 퍼미션을 지정하지 않는다면, 기본적으로 0644 가 사용된다.
전체 시크릿 볼륨에 대한 기본 모드를 설정하고 필요한 경우 키별로 오버라이드할 수도 있다.
이 경우, /etc/foo/my-group/my-username 에 있는 파일은
결과적으로 0777 퍼미션 값을 갖게 된다. JSON을 사용하는 경우, JSON 제한으로 인해
10진수 표기법(511)으로 모드를 지정해야 한다.
참고로 이 퍼미션 값은 나중에 읽을 때 10진수 표기법으로
표시될 수 있다.
볼륨에서 시크릿 값 사용하기
시크릿 볼륨을 마운트하는 컨테이너 내부에서, 시크릿 키는 파일로
나타나고 시크릿 값은 base64로 디코딩되어 이런 파일 내에 저장된다.
다음은 위의 예에서 컨테이너 내부에서 실행된 명령의 결과이다.
ls /etc/foo/
출력 결과는 다음과 비슷하다.
username
password
cat /etc/foo/username
출력 결과는 다음과 비슷하다.
admin
cat /etc/foo/password
출력 결과는 다음과 비슷하다.
1f2d1e2e67df
컨테이너의 프로그램은 파일에서 시크릿을 읽는 역할을
한다.
마운트된 시크릿은 자동으로 업데이트됨
볼륨에서 현재 사용되는 시크릿이 업데이트되면, 투영된 키도 결국 업데이트된다.
kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 상태인지 여부를 확인한다.
그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다.
캐시의 유형은 KubeletConfiguration 구조체의
ConfigMapAndSecretChangeDetectionStrategy 필드를 사용하여 구성할 수 있다.
시크릿은 watch(기본값), ttl 기반 또는 API 서버로 모든 요청을 직접
리디렉션하여 전파할 수 있다.
결과적으로, 시크릿이 업데이트된 순간부터 새로운 키가 파드에 투영되는
순간까지의 총 지연 시간은 kubelet 동기화 시간 + 캐시
전파 지연만큼 길 수 있다. 여기서 캐시 전파 지연은 선택한 캐시 유형에 따라
달라질 수 있다(캐시 전파 지연은 각 캐시 유형에 따라 watch 전파 지연, 캐시의 ttl, 또는 0 에 상응함).
참고: 시크릿을 subPath
볼륨 마운트로 사용하는 컨테이너는 시크릿 업데이트를
받지 않는다.
환경 변수에서 시크릿을 사용하는 컨테이너 내부에서, 시크릿 키는
시크릿 데이터의 base64 디코딩된 값을 포함하는 일반 환경 변수로 나타난다.
다음은 위의 예에서 컨테이너 내부에서 실행된 명령의 결과이다.
echo$SECRET_USERNAME
출력 결과는 다음과 비슷하다.
admin
echo$SECRET_PASSWORD
출력 결과는 다음과 비슷하다.
1f2d1e2e67df
시크릿 업데이트 후 환경 변수가 업데이트되지 않음
컨테이너가 환경 변수에서 이미 시크릿을 사용하는 경우, 다시 시작하지 않는 한 컨테이너에서 시크릿 업데이트를 볼 수 없다.
시크릿이 변경될 때 재시작을 트리거하는 써드파티 솔루션이 있다.
변경할 수 없는(immutable) 시크릿
FEATURE STATE:Kubernetes v1.19 [beta]
쿠버네티스 베타 기능인 변경할 수 없는 시크릿과 컨피그맵 은
개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
다음과 같은 이점이 있다.
애플리케이션 중단을 유발할 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
크게 줄임으로써 클러스터의 성능을 향상시킴
이 기능은 v1.19부터 기본적으로 활성화된 ImmutableEphemeralVolumes기능 게이트에
의해 제어된다. immutable 필드를 true 로 설정하여
변경할 수 없는 시크릿을 생성할 수 있다. 다음은 예시이다.
참고: 시크릿 또는 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
data 필드 내용을 변경할 수 없다. 시크릿을 삭제하고 다시 생성할 수만 있다.
기존 파드는 삭제된 시크릿에 대한 마운트 포인트를 유지하며, 이러한 파드를 다시 생성하는 것을
권장한다.
imagePullSecrets 사용하기
imagePullSecrets 필드는 동일한 네임스페이스의 시크릿에 대한 참조 목록이다.
imagePullSecretsDocker 를 사용하여 도커(또는 다른 컨테이너) 이미지 레지스트리
비밀번호가 포함된 시크릿을 kubelet에 전달할 수 있다. kubelet은 이 정보를 사용해서 파드를 대신하여 프라이빗 이미지를 가져온다.
imagePullSecrets 필드에 대한 자세한 정보는 PodSpec API를 참고한다.
수동으로 imagePullSecrets 를 생성하고, 서비스어카운트(ServiceAccount)에서
참조할 수 있다. 해당 서비스어카운트로 생성되거나
기본적인 서비스어카운트로 생성된 모든 파드는 파드의 imagePullSecrets
필드를 가져오고 서비스 어카운트의 필드로 설정한다.
해당 프로세스에 대한 자세한 설명은
서비스 어카운트에 ImagePullSecrets 추가하기를 참고한다.
상세 내용
제약 사항
시크릿 볼륨 소스는 지정된 오브젝트 참조가
실제로 시크릿 유형의 오브젝트를 가리키는지 확인하기 위해 유효성을 검사한다. 따라서, 시크릿에
의존하는 모든 파드보다 먼저 시크릿을 만들어야 한다.
시크릿 리소스는 네임스페이스에 존재한다.
시크릿은 동일한 네임스페이스에 있는 파드에서만 참조할 수 있다.
개별 시크릿의 크기는 1MiB로 제한된다. 이는 API 서버와
kubelet 메모리를 소진시키는 매우 큰 시크릿 생성을 막기 위한 것이다.
그러나, 많은 작은 시크릿을 만들어도 메모리가 고갈될 수 있다. 시크릿으로
인한 메모리 사용에 대한 보다 포괄적인 제한은 향후 버전에 계획된 기능이다.
kubelet은 API 서버에서 시크릿을 가져오는 파드에 대한
시크릿 사용만 지원한다.
여기에는 kubectl 을 사용하거나, 레플리케이션 컨트롤러를 통해 간접적으로 생성된 모든
파드가 포함된다. kubelet의 --manifest-url 플래그, --config 플래그 또는
kubectl의 REST API(이 방법들은 파드를 생성하는 일반적인 방법이 아님)로
생성된 파드는 포함하지 않는다.
시크릿은 optional(선택 사항)로 표시되지 않는 한 파드에서 환경
변수로 사용되기 전에 생성되어야 한다. 존재하지 않는 시크릿을
참조하면 파드가 시작되지 않는다.
명명된 시크릿에 존재하지 않는 키에 대한 참조(secretKeyRef 필드)는
파드가 시작되지 않도록 한다.
잘못된 환경 변수 이름으로 간주되는 키가 있는 envFrom 필드로
환경 변수를 채우는 데 사용되는 시크릿은 해당 키를
건너뛴다. 이러면 해당 파드가 시작될 수 있다. 원인이 InvalidVariableNames 인
이벤트가 발생하며 건너뛴 유효하지 않은 키 목록이
포함된 메시지가 생성된다. 다음의 예는 2개의 유효하지 않은
키(1badkey 와 2alsobad)가 포함된 default/mysecret을 참조하는 파드를 보여준다.
kubectl get events
출력 결과는 다음과 비슷하다.
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON
0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names.
시크릿 및 파드 수명 상호 작용
쿠버네티스 API를 호출하여 파드가 생성될 때, 참조된 시크릿이 있는지 확인하지
않는다. 일단 파드가 스케줄되면, kubelet은 시크릿 값 가져오기를
시도한다. 시크릿이 존재하지 않거나 API 서버에 대한
일시적인 연결 부족으로 인해 시크릿을 가져올 수 없는 경우, kubelet은
주기적으로 재시도한다. kubelet은 아직 시작되지 않은 이유를 설명하는
파드에 대한 이벤트를 보고한다. 시크릿을 가져오면, kubelet은
이를 포함하는 볼륨을 생성하고 마운트한다. 모든 파드의 볼륨이
마운트될 때까지 파드의 컨테이너는 시작되지 않는다.
$, \, *, = 그리고 ! 와 같은 특수 문자는 사용자의 셸에 의해 해석되고 이스케이핑이 필요하다.
대부분의 셸에서 비밀번호를 이스케이프하는 가장 쉬운 방법은 작은 따옴표(')로 묶는 것이다.
예를 들어, 실제 비밀번호가 S!B\*d$zDsb= 이면, 다음과 같은 명령을 실행해야 한다.
볼륨은 .secret-file 이라는 하나의 파일을 포함하고,
dotfile-test-container 는 /etc/secret-volume/.secret-file 경로에
이 파일을 가지게 된다.
참고:ls -l 명령의 결과에서 숨겨진 점으로 시작하는 파일들은
디렉터리 내용을 나열할 때 ls -la 를 사용해야 이 파일들을 볼 수 있다.
사용 사례: 파드의 한 컨테이너에 표시되는 시크릿
HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음, HMAC이 있는 일부 메시지에
서명해야 하는 프로그램을 고려한다. 애플리케이션 로직이
복잡하기 때문에, 서버에서 눈에 띄지 않는 원격 파일 읽기 공격이
있을 수 있으며, 이로 인해 개인 키가 공격자에게 노출될 수 있다.
이는 두 개의 컨테이너의 두 개 프로세스로 나눌 수 있다. 사용자 상호 작용과
비즈니스 로직을 처리하지만, 개인 키를 볼 수 없는 프론트엔드 컨테이너와
개인 키를 볼 수 있고, 프론트엔드의 간단한 서명 요청(예를 들어, localhost 네트워킹을 통해)에
응답하는 서명자 컨테이너로 나눌 수 있다.
이 분할된 접근 방식을 사용하면, 공격자는 이제 애플리케이션 서버를 속여서
파일을 읽는 것보다 다소 어려운 임의적인 어떤 작업을 수행해야
한다.
모범 사례
시크릿 API를 사용하는 클라이언트
시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, RBAC과 같은 인가 정책을
사용하여 접근를 제한해야 한다.
시크릿은 종종 다양한 중요도에 걸친 값을 보유하며, 이 중 많은 부분이
쿠버네티스(예: 서비스 어카운트 토큰)와 외부 시스템으로 단계적으로
확대될 수 있다. 개별 앱이 상호 작용할 것으로 예상되는 시크릿의 힘에 대해 추론할 수 있더라도
동일한 네임스페이스 내의 다른 앱이 이러한 가정을
무효화할 수 있다.
이러한 이유로 네임스페이스 내 시크릿에 대한 watch 와 list 요청은
매우 강력한 기능이며, 시크릿을 나열하면 클라이언트가 해당 네임스페이스에
있는 모든 시크릿의 값을 검사할 수 있기 때문에 피해야 한다. 클러스터의
모든 시크릿을 감시(watch)하고 나열(list)하는 기능은 가장 특권이 있는 시스템 레벨의
컴포넌트에 대해서만 예약되어야 한다.
시크릿 API에 접근해야 하는 애플리케이션은 필요한 시크릿에 대한 get 요청을
수행해야 한다. 이를 통해 관리자는 앱에 필요한
개별 인스턴스에 대한 접근을 허용 목록에 추가하면서 모든 시크릿에 대한 접근을
제한할 수 있다.
get 반복을 통한 성능 향상을 위해, 클라이언트는 시크릿을
참조한 다음 리소스를 감시(watch)하고, 참조가 변경되면 시크릿을 다시 요청하는 리소스를
설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(watch)하도록 하는 "대량 감시" API도
제안되었으며, 쿠버네티스의 후속 릴리스에서 사용할 수
있을 것이다.
보안 속성
보호
시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수
있으므로, 파드 생성, 보기, 편집 워크플로 중에
시크릿이 노출될 위험이 적다. 또한 시스템은 가능한 경우
디스크에 기록하지 않는 등 시크릿에 대한 추가 예방 조치를
취할 수 있다.
해당 노드의 파드에 필요한 경우에만 시크릿이 노드로 전송된다.
kubelet은 시크릿이 디스크 저장소에 기록되지 않도록 시크릿을
tmpfs 에 저장한다. 일단 시크릿에 의존하는 파드가 삭제되면, kubelet은
시크릿 데이터의 로컬 복제본도 삭제한다.
동일한 노드의 여러 파드에 대한 시크릿이 있을 수 있다. 그러나
파드가 요청하는 시크릿만 해당 컨테이너 내에서 잠재적으로 볼 수 있다.
따라서, 하나의 파드는 다른 파드의 시크릿에 접근할 수 없다.
파드에는 여러 개의 컨테이너가 있을 수 있다. 그러나, 파드의 각 컨테이너는
컨테이너 내에서 볼 수 있도록 파드의 volumeMounts 에 있는 시크릿 볼륨을
요청해야 한다. 이것은 유용한 파드 레벨에서의 보안
파티션을 구성하는 데 사용할 수 있다.
대부분의 쿠버네티스 배포판에서, 사용자와 API 서버 간,
API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
이러한 채널을 통해 전송될 때 시크릿이 보호된다.
파드를 지정할 때,
컨테이너에 필요한 각 리소스의 양을 선택적으로 지정할 수 있다.
지정할 가장 일반적인 리소스는 CPU와 메모리(RAM) 그리고 다른 것들이 있다.
파드에서 컨테이너에 대한 리소스 요청(request) 을 지정하면, 스케줄러는 이 정보를
사용하여 파드가 배치될 노드를 결정한다. 컨테이너에 대한 리소스 제한(limit) 을
지정하면, kubelet은 실행 중인 컨테이너가 설정한 제한보다 많은 리소스를
사용할 수 없도록 해당 제한을 적용한다. 또한 kubelet은
컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 요청 량을
예약한다.
요청 및 제한
파드가 실행 중인 노드에 사용 가능한 리소스가 충분하면, 컨테이너가 해당
리소스에 지정한 request 보다 더 많은 리소스를 사용할 수 있도록 허용된다.
그러나, 컨테이너는 리소스 limit 보다 더 많은 리소스를 사용할 수는 없다.
예를 들어, 컨테이너에 대해 256MiB의 memory 요청을 설정하고, 해당 컨테이너가
8GiB의 메모리를 가진 노드로 스케줄된 파드에 있고 다른 파드는 없는 경우, 컨테이너는 더 많은 RAM을
사용할 수 있다.
해당 컨테이너에 대해 4GiB의 memory 제한을 설정하면, kubelet(그리고
컨테이너 런타임)이 제한을 적용한다.
런타임은 컨테이너가 구성된 리소스 제한을 초과하여 사용하지 못하게 한다. 예를 들어,
컨테이너의 프로세스가 허용된 양보다 많은 메모리를 사용하려고 하면,
시스템 커널은 메모리 부족(out of memory, OOM) 오류와 함께 할당을 시도한 프로세스를
종료한다.
제한은 반응적(시스템이 위반을 감지한 후에 개입)으로
또는 강제적(시스템이 컨테이너가 제한을 초과하지 않도록 방지)으로 구현할 수 있다. 런타임마다
다른 방식으로 동일한 제약을 구현할 수 있다.
참고: 컨테이너가 자체 메모리 제한을 지정하지만, 메모리 요청을 지정하지 않는 경우, 쿠버네티스는
제한과 일치하는 메모리 요청을 자동으로 할당한다. 마찬가지로, 컨테이너가 자체 CPU 제한을
지정하지만, CPU 요청을 지정하지 않는 경우, 쿠버네티스는 제한과 일치하는 CPU 요청을 자동으로
할당한다.
리소스 타입
CPU 와 메모리 는 각각 리소스 타입 이다. 리소스 타입에는 기본 단위가 있다.
CPU는 컴퓨팅 처리를 나타내며 쿠버네티스 CPU 단위로 지정된다.
메모리는 바이트 단위로 지정된다.
쿠버네티스 v1.14 이상을 사용하는 경우, huge page 리소스를 지정할 수 있다.
Huge page는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리
블록을 할당하는 리눅스 관련 기능이다.
예를 들어, 기본 페이지 크기가 4KiB인 시스템에서, hugepages-2Mi: 80Mi 제한을
지정할 수 있다. 컨테이너가 40개 이상의 2MiB huge page(총 80MiB)를
할당하려고 하면 해당 할당이 실패한다.
참고:hugepages-* 리소스를 오버커밋할 수 없다.
이것은 memory 및 cpu 리소스와는 다르다.
CPU와 메모리를 통칭하여 컴퓨트 리소스 또는 리소스 라고 한다. 컴퓨트
리소스는 요청, 할당 및 소비될 수 있는 측정 가능한
수량이다. 이것은
API 리소스와는 다르다. 파드 및
서비스와 같은 API 리소스는
쿠버네티스 API 서버를 통해 읽고 수정할 수
있는 오브젝트이다.
요청과 제한은 개별 컨테이너에서만 지정할 수 있지만,
파드 리소스 요청 및 제한에 대해 이야기하는 것이 편리하다.
특정 리소스 타입에 대한 파드 리소스 요청/제한 은 파드의 각 컨테이너에 대한
해당 타입의 리소스 요청/제한의 합이다.
쿠버네티스의 리소스 단위
CPU의 의미
CPU 리소스에 대한 제한 및 요청은 cpu 단위로 측정된다.
쿠버네티스의 CPU 1개는 클라우드 공급자용 vCPU/Core 1개 와 베어메탈 인텔 프로세서에서의 1개 하이퍼스레드 에 해당한다.
분수의 요청이 허용된다.
0.5 의 spec.containers[].resources.requests.cpu 요청을 가진
컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. 0.1 이라는 표현은
"백 밀리cpu"로 읽을 수 있는 100m 표현과 동일하다. 어떤 사람들은
"백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다.
0.1 과 같이 소수점이 있는 요청은 API에 의해 100m 로 변환되며,
1m 도 허용되지 않게 정밀하다. 이러한 이유로, 100m 형식이
선호될 수 있다.
CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다.
0.1은 단일 코어, 이중 코어 또는 48코어 시스템에서 동일한 양의 CPU이다.
메모리의 의미
memory 에 대한 제한 및 요청은 바이트 단위로 측정된다.
E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를
일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와
같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.
128974848, 129e6, 129M, 123Mi
다음은 예제이다.
다음 파드에는 두 개의 컨테이너가 있다. 각 컨테이너에는 0.25 cpu와
64MiB(226 바이트)의 메모리 요청이 있다. 각 컨테이너는 0.5
cpu와 128MiB 메모리로 제한된다. 파드에 0.5 cpu와 128 MiB
메모리, 1 cpu와 256MiB 메모리 제한이 있다고 말할 수 있다.
파드를 생성할 때, 쿠버네티스 스케줄러는 파드를 실행할 노드를
선택한다. 각 노드는 파드에 제공할 수 있는 CPU와 메모리 양과 같은 각 리소스 타입에 대해
최대 용량을 갖는다. 스케줄러는 각 리소스 타입마다
스케줄된 컨테이너의 리소스 요청 합계가
노드 용량보다 작도록 한다. 참고로 노드의 실제 메모리나
CPU 리소스 사용량은 매우 적지만, 용량 확인에 실패한 경우
스케줄러는 여전히 노드에 파드를 배치하지 않는다. 이는 리소스 사용량이
나중에 증가할 때, 예를 들어, 일일 요청 비율이
최대일 때 노드의 리소스 부족을 방지한다.
리소스 제한이 있는 파드가 실행되는 방법
kubelet은 파드의 컨테이너를 시작할 때, CPU와 메모리 제한을
컨테이너 런타임으로 전달한다.
도커를 사용하는 경우에는 다음과 같다.
spec.containers[].resources.requests.cpu 는 잠재적인 분수이며,
1024를 곱한 값인 코어 값으로 변환된다. 이 숫자 또는 2보다
큰 값은 docker run 명령에서
--cpu-shares
플래그의 값으로 사용된다.
이 spec.containers[].resources.limits.cpu 값은 밀리코어 값으로 변환되고
100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 총 CPU
시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다.
참고: 기본 쿼터 기간은 100ms이다. 최소 CPU 쿼터는 1ms이다.
spec.containers[].resources.limits.memory 는 정수로 변환되어,
docker run 명령에서
--memory
플래그의 값으로 사용된다.
컨테이너가 메모리 제한을 초과하면, 컨테이너는 종료될 수 있다. 다시
시작할 수 있으면, 다른 타입의 런타임 오류와 마찬가지로, kubelet이 다시
시작한다.
컨테이너가 메모리 요청을 초과하면, 노드에 메모리가
부족할 때마다 파드가 축출될 수 있다.
컨테이너가 오랫동안 CPU 제한을 초과하는 것은 허용되거나 허용되지
않을 수 있다. 그러나, 과도한 CPU 사용으로 인해 종료되지는 않는다.
리소스 제한으로 인해 컨테이너를 스케줄할 수 없는지 또는
종료 중인지 확인하려면,
문제 해결 섹션을 참조한다.
컴퓨트 및 메모리 리소스 사용량 모니터링
파드의 리소스 사용량은 파드 상태의 일부로 보고된다.
클러스터에서 선택적인 모니터링 도구를
사용할 수 있다면, 메트릭 API에서
직접 또는 모니터링 도구에서 파드 리소스
사용량을 검색할 수 있다.
로컬 임시(ephemeral) 스토리지
FEATURE STATE:Kubernetes v1.10 [beta]
노드에는 로컬에 연결된 쓰기 가능 장치 또는, 때로는 RAM에 의해
지원되는 로컬 임시 스토리지가 있다.
"임시"는 내구성에 대한 장기간의 보증이 없음을 의미한다.
파드는 스크래치 공간, 캐싱 및 로그에 대해 임시 로컬 스토리지를 사용한다.
kubelet은 로컬 임시 스토리지를 사용하여 컨테이너에
emptyDir볼륨을 마운트하기 위해 파드에 스크래치 공간을 제공할 수 있다.
kubelet은 이러한 종류의 스토리지를 사용하여
노드-레벨 컨테이너 로그,
컨테이너 이미지 및 실행 중인 컨테이너의 쓰기 가능 계층을 보유한다.
주의: 노드가 실패하면, 임시 스토리지의 데이터가 손실될 수 있다.
애플리케이션은 로컬 임시 스토리지에서 성능에 대한 SLA(예: 디스크 IOPS)를
기대할 수 없다.
베타 기능에서, 쿠버네티스는 파드가 사용할 수 있는 임시 로컬 스토리지의 양을
추적, 예약 및 제한할 수 있도록 해준다.
ephemeral-storage 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, K와
같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
예를 들어, 다음은 대략 동일한 값을 나타낸다.
128974848, 129e6, 129M, 123Mi
다음 예에서, 파드에 두 개의 컨테이너가 있다. 각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다. 각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다. 따라서, 파드는 4GiB의 로컬 임시 스토리지 요청과 8GiB 로컬 임시 스토리지 제한을 가진다.
파드를 생성할 때, 쿠버네티스 스케줄러는 파드를 실행할 노드를
선택한다. 각 노드에는 파드에 제공할 수 있는 최대 임시 스토리지 공간이 있다. 자세한 정보는, 노드 할당 가능을 참조한다.
스케줄러는 스케줄된 컨테이너의 리소스 요청 합계가 노드 용량보다 작도록 한다.
임시 스토리지 소비 관리
kubelet이 로컬 임시 스토리지를 리소스로 관리하는 경우,
kubelet은 다음에서 스토리지 사용을 측정한다.
tmpfsemptyDir 볼륨을 제외한 emptyDir 볼륨
노드-레벨 로그가 있는 디렉터리
쓰기 가능한 컨테이너 계층
허용하는 것보다 더 많은 임시 스토리지를 파드가 사용하는 경우, kubelet은
파드 축출을 트리거하는 축출 신호를 설정한다.
컨테이너-레벨 격리의 경우, 컨테이너의 쓰기 가능한 계층과 로그
사용량이 스토리지 제한을 초과하면, kubelet은 파드를 축출하도록 표시한다.
파드-레벨 격리에 대해 kubelet은 해당 파드의 컨테이너에 대한 제한을 합하여
전체 파드 스토리지 제한을 해결한다. 이 경우, 모든
컨테이너와 파드의 emptyDir 볼륨의 로컬 임시 스토리지 사용량 합계가
전체 파드 스토리지 제한을 초과하면, kubelet은 파드를 축출 대상으로
표시한다.
주의:
kubelet이 로컬 임시 스토리지를 측정하지 않는 경우,
로컬 스토리지 제한을 초과하는 파드는 로컬 스토리지 리소스 제한을
위반해도 축출되지 않는다.
그러나, 쓰기 가능한 컨테이너 계층, 노드-레벨 로그
또는 emptyDir 볼륨의 파일 시스템 공간이 부족하면, 로컬
스토리지가 부족하다고 노드 자체에 테인트되고
이로인해 특별히 이 테인트를 허용하지 않는 모든 파드를 축출하도록 트리거한다.
kubelet은 각 emptyDir 볼륨, 컨테이너 로그 디렉터리 및 쓰기 가능한 컨테이너 계층을
스캔하는 정기적인 스케줄 검사를 수행한다.
스캔은 사용된 공간의 양을 측정한다.
참고:
이 모드에서, kubelet은 삭제된 파일의 열린 파일 디스크립터를
추적하지 않는다.
여러분(또는 컨테이너)이 emptyDir 볼륨 안에 파일을 생성하면,
그 파일이 열리고, 파일이 열려있는 동안 파일을
삭제하면, 삭제된 파일의 inode는 해당 파일을 닫을 때까지
유지되지만 kubelet은 사용 중인 공간으로 분류하지 않는다.
FEATURE STATE:Kubernetes v1.15 [alpha]
프로젝트 쿼터는 파일시스템에서 스토리지 사용을 관리하기 위한
운영체제 레벨의 기능이다. 쿠버네티스를 사용하면, 스토리지 사용을
모니터링하기 위해 프로젝트 쿼터를 사용할 수 있다. 노드에서 'emptyDir' 볼륨을
지원하는 파일시스템이 프로젝트 쿼터 지원을 제공하는지 확인한다.
예를 들어, XFS와 ext4fs는 프로젝트 쿼터를 지원한다.
참고: 프로젝트 쿼터를 통해 스토리지 사용을 모니터링할 수 있다. 이는 제한을 강제하지 않는다.
쿠버네티스는 1048576 부터 프로젝트 ID를 사용한다. 사용 중인 ID는
/etc/projects 와 /etc/projid 에 등록되어 있다. 이 범위의 프로젝트 ID가
시스템에서 다른 목적으로 사용되는 경우, 쿠버네티스가
이를 사용하지 않도록 해당 프로젝트 ID를 /etc/projects 와 /etc/projid 에
등록해야 한다.
쿼터는 디렉터리 검색보다 빠르고 정확하다. 디렉터리가
프로젝트에 할당되면, 디렉터리 아래에 생성된
모든 파일이 해당 프로젝트에 생성되며, 커널은 해당 프로젝트의
파일에서 사용 중인 블록 수를 추적하기만 하면 된다.
파일이 생성되고 삭제되었지만, 열린 파일 디스크립터가 있으면,
계속 공간을 소비한다. 쿼터 추적은 공간을 정확하게 기록하는 반면
디렉터리 스캔은 삭제된 파일이 사용한 스토리지를 간과한다.
프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다.
kubelet 구성의
featureGates 필드 또는 --feature-gates 커맨드 라인 플래그를 사용하여
LocalStorageCapacityIsolationFSQuotaMonitoring=true기능 게이트를
활성화한다.
루트 파일시스템(또는 선택적인 런타임 파일시스템)에
프로젝트 쿼터가 활성화되어 있는지 확인한다. 모든 XFS 파일시스템은 프로젝트 쿼터를 지원한다.
ext4 파일시스템의 경우, 파일시스템이 마운트되지 않은 상태에서 프로젝트 쿼터
추적 기능을 활성화해야 한다.
# ext4인 /dev/block-device가 마운트되지 않은 경우
sudo tune2fs -O project -Q prjquota /dev/block-device
루트 파일시스템(또는 선택적인 런타임 파일시스템)은 프로젝트 쿼터를
활성화한 상태에서 마운트해야 힌다. XFS와 ext4fs 모두에서,
마운트 옵션의 이름은 prjquota 이다.
확장된 리소스
확장된 리소스는 kubernetes.io 도메인 외부의 전체 주소(fully-qualified)
리소스 이름이다. 쿠버네티스에 내장되지 않은 리소스를 클러스터 운영자가 알리고
사용자는 사용할 수 있다.
확장된 리소스를 사용하려면 두 단계가 필요한다. 먼저, 클러스터
운영자는 확장된 리소스를 알려야 한다. 둘째, 사용자는 파드의
확장된 리소스를 요청해야 한다.
새로운 노드-레벨의 확장된 리소스를 알리기 위해, 클러스터 운영자는
API 서버에 PATCH HTTP 요청을 제출하여 클러스터의
노드에 대해 status.capacity 에서 사용할 수 있는 수량을 지정할 수 있다. 이 작업
후에는, 노드의 status.capacity 에 새로운 리소스가 포함된다. 이
status.allocatable 필드는 kubelet에 의해 비동기적으로 새로운
리소스로 자동 업데이트된다. 참고로 스케줄러가 파드 적합성을 평가할 때 노드
status.allocatable 값을 사용하므로, 노드 용량을
새 리소스로 패치하는 것과 해당 노드에서 리소스를 스케줄하도록 요청하는 첫 번째 파드
사이에 약간의 지연이 있을 수 있다.
예제:
다음은 curl 을 사용하여 마스터가 k8s-master 인 노드 k8s-node-1 에
5개의 "example.com/foo" 리소스를 알리는 HTTP 요청을 구성하는 방법을
보여주는 예이다.
프로세스 ID(PID) 제한은 kubelet의 구성에 대해 주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다. 자세한 내용은 Pid 제한을 참고한다.
문제 해결
내 파드가 failedScheduling 이벤트 메시지로 보류 중이다
파드가 배치될 수 있는 노드를 스케줄러가 찾을 수 없으면, 노드를
찾을 수 있을 때까지 파드는 스케줄되지 않은 상태로 유지한다. 스케줄러가 다음과 같이
파드의 위치를 찾지 못하면 이벤트가 생성된다.
kubectl describe pod frontend | grep -A 3 Events
Events:
FirstSeen LastSeen Count From Subobject PathReason Message
36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others
위의 예에서, 노드의 CPU 리소스가 충분하지 않아 이름이
"frontend"인 파드를 스케줄하지 못했다. 비슷한 메시지로
메모리 부족(PodExceedsFreeMemory)으로 인한 장애도 알릴 수 있다. 일반적으로, 파드가
이 타입의 메시지로 보류 중인 경우, 몇 가지 시도해 볼 것들이 있다.
클러스터에 더 많은 노드를 추가한다.
불필요한 파드를 종료하여 보류 중인 파드를 위한 공간을 확보한다.
파드가 모든 노드보다 크지 않은지 확인한다. 예를 들어, 모든
노드의 용량이 cpu: 1 인 경우, cpu: 1.1 요청이 있는 파드는
절대 스케줄되지 않는다.
kubectl describe nodes 명령으로 노드 용량과 할당된 양을
확인할 수 있다. 예를 들면, 다음과 같다.
kubectl describe nodes e2e-test-node-pool-4lw4
Name: e2e-test-node-pool-4lw4
[ ... 명확하게 하기 위해 라인들을 제거함 ...]
Capacity:
cpu: 2
memory: 7679792Ki
pods: 110
Allocatable:
cpu: 1800m
memory: 7474992Ki
pods: 110
[ ... 명확하게 하기 위해 라인들을 제거함 ...]
Non-terminated Pods: (5 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%)
kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%)
kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%)
kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%)
kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%)
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%)
위의 출력에서, 파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를
요청하는 것은 노드에 맞지 않음을 알 수 있다.
Pods 섹션을 살펴보면, 파드가 노드에서 공간을 차지하는 것을
볼 수 있다.
시스템 데몬이 사용 가능한 리소스의 일부를 사용하기 때문에, 파드에
사용 가능한 리소스의 양이 노드 용량보다 적다. allocatable 필드
NodeStatus는
파드가 사용할 수 있는 리소스의 양을 제공한다. 자세한 정보는
노드 할당 가능 리소스를 참조한다.
리소스 쿼터 기능은
소비될 수 있는 리소스의 총량을 제한하도록 구성할 수 있다. 네임스페이스와
함께 사용하면, 한 팀이 모든 리소스를 사용하는 경우를 방지할 수 있다.
내 컨테이너가 종료되었다
리소스가 부족하여 컨테이너가 종료될 수 있다. 리소스
제한에 도달하여 컨테이너가 종료되고 있는지 확인하려면,
관심있는 파드에 대해 kubectl describe pod 를 호출한다.
kubectl describe pod simmemleak-hra99
Name: simmemleak-hra99
Namespace: default
Image(s): saadali/simmemleak
Node: kubernetes-node-tf0f/10.240.216.66
Labels: name=simmemleak
Status: Running
Reason:
Message:
IP: 10.244.2.75
Replication Controllers: simmemleak (1/1 replicas created)
Containers:
simmemleak:
Image: saadali/simmemleak
Limits:
cpu: 100m
memory: 50Mi
State: Running
Started: Tue, 07 Jul 2015 12:54:41 -0700
Last Termination State: Terminated
Exit Code: 1
Started: Fri, 07 Jul 2015 12:54:30 -0700
Finished: Fri, 07 Jul 2015 12:54:33 -0700
Ready: False
Restart Count: 5
Conditions:
Type Status
Ready False
Events:
FirstSeen LastSeen Count From SubobjectPath Reason Message
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
앞의 예제에서, Restart Count: 5 표시는 파드의 simmemleak
컨테이너가 종료되고 5번 다시 시작되었음을 나타낸다.
이전에 종료된 컨테이너의 상태를 가져오기 위해 -o go-template=... 옵션을 사용해서
kubectl get pod 를 호출할 수 있다.
kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99
여러 클러스터가 있고, 사용자와 구성 요소가 다양한 방식으로 인증한다고 가정하자.
예를 들면 다음과 같다.
실행 중인 kubelet은 인증서를 이용하여 인증할 수 있다.
사용자는 토큰으로 인증할 수 있다.
관리자는 개별 사용자에게 제공하는 인증서 집합을 가지고 있다.
kubeconfig 파일을 사용하면 클러스터와 사용자와 네임스페이스를 구성할 수 있다.
또한 컨텍스트를 정의하여
빠르고 쉽게 클러스터와 네임스페이스 간에 전환할 수 있다.
컨텍스트
kubeconfig에서 컨텍스트 요소는 편리한 이름으로 접속 매개 변수를 묶는데 사용한다.
각 컨텍스트는 클러스터, 네임스페이스와 사용자라는 세 가지 매개 변수를 가진다.
기본적으로 kubectl 커맨드라인 툴은 현재 컨텍스트 의 매개 변수를
사용하여 클러스터와 통신한다.
현재 컨택스트를 선택하려면 다음을 실행한다.
kubectl config use-context
KUBECONFIG 환경 변수
KUBECONFIG 환경 변수는 kubeconfig 파일 목록을 보유한다.
리눅스 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다.
윈도우는 세미콜론(;)으로 구분한다. KUBECONFIG 환경 변수가 필수는 아니다.
KUBECONFIG 환경 변수가 없으면,
kubectl은 기본 kubeconfig 파일인 $HOME/.kube/config를 사용한다.
KUBECONFIG 환경 변수가 존재하면, kubectl은
KUBECONFIG 환경 변수에 나열된 파일을 병합한 결과 형태의
효과적 구성을 이용한다.
kubeconfig 파일 병합
구성을 보려면, 다음 커맨드를 입력한다.
kubectl config view
앞서 설명한 것처럼, 이 출력 내용은 단일 kubeconfig 파일이나
여러 kubeconfig 파일을 병합한 결과 일 수 있다.
다음은 kubeconfig 파일을 병합할 때에 kubectl에서 사용하는 규칙이다.
--kubeconfig 플래그를 설정했으면, 지정한 파일만 사용한다. 병합하지 않는다.
이 플래그는 오직 한 개 인스턴스만 허용한다.
그렇지 않고, KUBECONFIG 환경 변수를 설정하였다면
병합해야 하는 파일의 목록으로 사용한다.
KUBECONFIG 환경 변수의 나열된 파일은
다음 규칙에 따라 병합한다.
빈 파일명은 무시한다.
역 직렬화 불가한 파일 내용에 대해서 오류를 일으킨다.
특정 값이나 맵 키를 설정한 첫 번째 파일을 우선한다.
값이나 맵 키를 변경하지 않는다.
예: 현재 컨텍스트를 설정할 첫 번째 파일의 컨택스트를 유지한다.
예: 두 파일이 red-user를 지정했다면, 첫 번째 파일의 red-user 값만을 사용한다.
두 번째 파일의 red-user 하위에 충돌하지 않는 항목이 있어도 버린다.
프라이어리티클래스는 프라이어리티 클래스 이름에서 우선순위의 정수 값으로의 매핑을
정의하는 네임스페이스가 아닌(non-namespaced) 오브젝트이다. 이름은
프라이어리티클래스 오브젝트의 메타데이터의 name 필드에 지정된다. 값은
필수 value 필드에 지정되어 있다. 값이 클수록, 우선순위가
높다.
프라이어리티클래스 오브젝트의 이름은 유효한
DNS 서브 도메인 이름이어야 하며,
system- 접두사를 붙일 수 없다.
프라이어리티클래스 오브젝트는 10억 이하의 32비트 정수 값을 가질
수 있다. 일반적으로 선점하거나 축출해서는 안되는 중요한 시스템 파드에는 더 큰 숫자가
예약되어 있다. 클러스터 관리자는 원하는 각 매핑에 대해 프라이어리티클래스 오브젝트를
하나씩 생성해야 한다.
프라이어리티클래스에는 globalDefault 와 description 두 개의 선택적인 필드도 있다.
globalDefault 필드는 이 프라이어리티클래스의 값을 priorityClassName 이 없는
파드에 사용해야 함을 나타낸다. 시스템에서 globalDefault 가 true 로 설정된
프라이어리티클래스는 하나만 존재할 수 있다. globalDefault 가 설정된
프라이어리티클래스가 없을 경우, priorityClassName 이 없는 파드의
우선순위는 0이다.
description 필드는 임의의 문자열이다. 이 필드는 이 프라이어리티클래스를 언제
사용해야 하는지를 클러스터 사용자에게 알려주기 위한 것이다.
PodPriority와 기존 클러스터에 대한 참고 사항
이 기능없이 기존 클러스터를 업그레이드 하는 경우, 기존 파드의
우선순위는 사실상 0이다.
globalDefault 가 true 로 설정된 프라이어리티클래스를 추가해도 기존 파드의
우선순위는 변경되지 않는다. 이러한 프라이어리티클래스의 값은
프라이어리티클래스를 추가한 후 생성된 파드에만 사용된다.
프라이어리티클래스를 삭제하면, 삭제된 프라이어리티클래스의 이름을 사용하는
기존 파드는 변경되지 않고 남아있지만, 삭제된 프라이어리티클래스의 이름을
사용하는 파드는 더 이상 생성할 수 없다.
프라이어리티클래스 예제
apiVersion:scheduling.k8s.io/v1kind:PriorityClassmetadata:name:high-priorityvalue:1000000globalDefault:falsedescription:"이 프라이어리티 클래스는 XYZ 서비스 파드에만 사용해야 한다."
비-선점 프라이어리티클래스
FEATURE STATE:Kubernetes v1.19 [beta]
PreemptionPolicy: Never 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
앞쪽에 배치되지만,
그 파드는 다른 파드를 축출할 수 없다.
스케줄링 대기 중인 비-선점 파드는 충분한 리소스가 확보되고
스케줄링될 수 있을 때까지
스케줄링 대기열에 대기한다.
다른 파드와 마찬가지로,
비-선점 파드는
스케줄러 백오프(back-off)에 종속된다.
이는 스케줄러가 이러한 파드를 스케줄링하려고 시도하고 스케줄링할 수 없는 경우,
더 적은 횟수로 재시도하여,
우선순위가 낮은 다른 파드를 미리 스케줄링할 수 있음을 의미한다.
비-선점 파드는 다른 우선순위가 높은 파드에 의해
축출될 수 있다.
PreemptionPolicy 는 기본값으로 PreemptLowerPriority 로 설정되어,
해당 프라이어리티클래스의 파드가 우선순위가 낮은 파드를 축출할 수
있다(기존의 기본 동작과 동일).
PreemptionPolicy 가 Never 로 설정된 경우,
해당 프라이어리티클래스의 파드는 비-선점될 것이다.
예제 유스케이스는 데이터 과학 관련 워크로드이다.
사용자는 다른 워크로드보다 우선순위가 높은 잡(job)을 제출할 수 있지만,
실행 중인 파드를 축출하여 기존의 작업을 삭제하지는 않을 것이다.
클러스터 리소스가 "자연스럽게" 충분히 사용할 수 있게 되면,
PreemptionPolicy: Never 의 우선순위가 높은 잡이
다른 대기 중인 파드보다 먼저 스케줄링된다.
비-선점 프라이어리티클래스 예제
apiVersion:scheduling.k8s.io/v1kind:PriorityClassmetadata:name:high-priority-nonpreemptingvalue:1000000preemptionPolicy:NeverglobalDefault:falsedescription:"이 프라이어리티 클래스는 다른 파드를 축출하지 않는다."
파드 우선순위
프라이어리티클래스가 하나 이상 있으면, 그것의 명세에서 이들 프라이어리티클래스 이름 중 하나를
지정하는 파드를 생성할 수 있다. 우선순위 어드미션
컨트롤러는 priorityClassName 필드를 사용하고 우선순위의 정수 값을
채운다. 프라이어리티 클래스를 찾을 수 없으면, 파드가 거부된다.
다음의 YAML은 이전 예제에서 생성된 프라이어리티클래스를
사용하는 파드 구성의 예이다. 우선순위 어드미션 컨트롤러는
명세를 확인하고 파드의 우선순위를 1000000으로
해석한다.
파드 우선순위가 활성화되면, 스케줄러가 우선순위에 따라 보류 중인
파드를 주문하고 보류 중인 파드는 스케줄링 대기열에서
우선순위가 낮은 다른 보류 중인 파드보다 우선한다. 결과적으로, 스케줄링
요구 사항이 충족되는 경우 우선순위가 더 낮은 파드보다 우선순위가 높은 파드가
더 빨리 스케줄링될 수 있다. 이러한 파드를 스케줄링할 수 없는 경우,
스케줄러는 계속 진행하고 우선순위가 낮은 다른 파드를 스케줄링하려고 한다.
선점
파드가 생성되면, 대기열로 이동하여 스케줄링을 기다린다.
스케줄러가 대기열에서 파드를 선택하여 노드에 스케줄링하려고 한다.
파드의 지정된 모든 요구 사항을 충족하는 노드가 없으면,
보류 중인 파드에 대해 선점 로직이 트리거된다. 보류 중인 파드를 P라 하자.
선점 로직은 P보다 우선순위가 낮은 하나 이상의 파드를 제거하면
해당 노드에서 P를 스케줄링할 수 있는 노드를 찾는다. 이러한
노드가 발견되면, 하나 이상의 우선순위가 낮은 파드가 노드에서 축출된다.
파드가 축출된 후, P는 노드에 스케줄링될 수 있다.
사용자 노출 정보
파드 P가 노드 N에서 하나 이상의 파드를 축출할 경우, 파드 P의 상태 nominatedNodeName
필드는 노드 N의 이름으로 설정된다. 이 필드는 스케줄러가 파드 P에
예약된 리소스를 추적하는 데 도움이 되고 사용자에게 클러스터의 선점에 대한
정보를 제공한다.
파드 P는 반드시 "지정된 노드"로 스케줄링되지는 않는다.
피해자 파드가 축출된 후, 그것은 정상적(graceful)으로 종료되는 기간을 갖는다.
스케줄러가 종료될 피해자 파드를 기다리는 동안 다른 노드를 사용할 수
있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용한다. 그 결과,
파드 스펙의 nominatedNodeName 과 nodeName 은 항상 동일하지 않다. 또한,
스케줄러가 노드 N에서 파드를 축출했지만, 파드 P보다 우선순위가 높은 파드가
도착하면, 스케줄러가 노드 N에 새로운 우선순위가 높은 파드를 제공할 수 있다. 이러한
경우, 스케줄러는 파드 P의 nominatedNodeName 을 지운다. 이렇게하면, 스케줄러는
파드 P가 다른 노드에서 파드를 축출할 수 있도록 한다.
선점의 한계
선점 피해자의 정상적인 종료
파드가 축출되면, 축출된 피해자 파드는
정상적인 종료 기간을 가진다.
피해자 파드는 작업을 종료하고 빠져나가는 데(exit) 많은 시간을 가진다. 그렇지 않으면,
파드는 강제종료(kill) 된다. 이 정상적인 종료 기간은 스케줄러가 파드를 축출하는
지점과 보류 중인 파드(P)를 노드(N)에서 스케줄링할 수 있는 시점 사이의
시간 간격을 만든다. 그 동안, 스케줄러는 보류 중인 다른 파드를
계속 스케줄링한다. 피해자 파드가 빠져나가거나 종료되면, 스케줄러는 보류 대기열에서
파드를 스케줄하려고 한다. 따라서, 일반적으로 스케줄러가 피해자 파드를 축출하는 시점과
파드 P가 스케줄링된 시점 사이에 시간 간격이 있다.
이러한 차이를 최소화하기 위해, 우선순위가 낮은 파드의 정상적인 종료 기간을 0 또는
작은 수로 설정할 수 있다.
PodDisruptionBudget을 지원하지만, 보장하지 않음
Pod Disruption Budget(PDB)은
애플리케이션 소유자가 자발적 중단에서 동시에 다운된 복제된
애플리케이션의 파드 수를 제한할 수 있다. 쿠버네티스는 파드를
선점할 때 PDB를 지원하지만, PDB를 따르는 것이 최선의 노력이다. 스케줄러는
선점에 의해 PDB를 위반하지 않은 피해자 파드를 찾으려고 하지만, 그러한 피해자 파드가
발견되지 않으면, 선점은 여전히 발생하며, PDB를 위반하더라도 우선순위가
낮은 파드는 제거된다.
우선순위가 낮은 파드에 대한 파드-간 어피니티
이 질문에 대한 답변이 '예'인 경우에만 노드가 선점 대상으로 간주된다.
"대기 중인 파드보다 우선순위가 낮은 모든 파드가 노드에서
제거되면, 보류 중인 파드를 노드에 스케줄링할 수 있습니까?"
참고: 선점으로 우선순위가 낮은 모든 파드를 반드시 제거할 필요는
없다. 우선순위가 낮은 모든 파드보다 적은 수를 제거하여 보류 중인 파드를
스케줄링할 수 있는 경우, 우선순위가 낮은 파드의 일부만 제거된다.
그럼에도 불구하고, 앞의 질문에 대한 대답은 '예'여야 한다. 답변이 '아니오'인 경우,
노드가 선점 대상으로 간주되지 않는다.
보류 중인 파드가 노드에 있는 하나 이상의 우선순위가 낮은 파드에 대한 파드-간 어피니티를
가진 경우에, 우선순위가 낮은 파드가 없을 때 파드-간 어피니티 규칙을
충족할 수 없다. 이 경우, 스케줄러는 노드의 파드를 축출하지
않는다. 대신, 다른 노드를 찾는다. 스케줄러가
적합한 노드를 찾거나 찾지 못할 수 있다. 보류 중인 파드를 스케줄링할 수 있다는
보장은 없다.
이 문제에 대한 권장 솔루션은 우선순위가 같거나 높은 파드에 대해서만 파드-간 어피니티를
생성하는 것이다.
교차 노드 선점
보류 중인 파드 P가 노드 N에 스케줄링될 수 있도록 노드 N이 선점 대상으로 고려되고
있다고 가정한다. 다른 노드의 파드가 축출된 경우에만 P가 N에서 실행 가능해질 수
있다. 예를 들면 다음과 같다.
파드 P는 노드 N에 대해 고려된다.
파드 Q는 노드 N과 동일한 영역의 다른 노드에서 실행 중이다.
파드 P는 파드 Q(topologyKey: topology.kubernetes.io/zone)와 영역(zone) 전체의 안티-어피니티를 갖는다.
영역에서 파드 P와 다른 파드 간의 안티-어피니티에 대한 다른 경우는
없다.
노드 N에서 파드 P를 스케줄링하기 위해, 파드 Q를 축출할 수 있지만, 스케줄러는
교차-노드 선점을 수행하지 않는다. 따라서, 파드 P가 노드 N에서
스케줄링할 수 없는 것으로 간주된다.
파드 Q가 노드에서 제거되면, 파드 안티-어피니티 위반이
사라지고, 파드 P는 노드 N에서 스케줄링될 수 있다.
수요가 충분하고 합리적인 성능의 알고리즘을 찾을 경우
향후 버전에서 교차 노드 선점의 추가를 고려할 수 있다.
문제 해결
파드 우선순위와 선점은 원하지 않는 부작용을 가질 수 있다. 다음은
잠재적 문제의 예시와 이를 해결하는 방법이다.
파드가 불필요하게 선점(축출)됨
선점은 우선순위가 높은 보류 중인 파드를 위한 공간을 만들기 위해 리소스 압박을 받고 있는
클러스터에서 기존 파드를 제거한다. 실수로 특정 파드에 높은 우선순위를
부여하면, 의도하지 않은 높은 우선순위 파드가 클러스터에서
선점을 유발할 수 있다. 파드 우선순위는 파드 명세에서
priorityClassName 필드를 설정하여 지정한다. 그런 다음
우선순위의 정수 값이 분석되어 podSpec 의 priority 필드에 채워진다.
문제를 해결하기 위해, 해당 파드가 우선순위가 낮은 클래스를 사용하도록 priorityClassName 을
변경하거나, 해당 필드를 비워둘 수 있다. 빈
priorityClassName 은 기본값이 0으로 해석된다.
파드가 축출되면, 축출된 파드에 대한 이벤트가 기록된다.
선점은 클러스터가 파드에 대한 리소스를 충분히 가지지 못한 경우에만
발생한다. 이러한 경우, 선점은 보류 중인 파드(선점자)의 우선순위가
피해자 파드보다 높은 경우에만 발생한다. 보류 중인 파드가 없거나,
보류 중인 파드의 우선순위가 피해자 파드와 같거나 낮은 경우
선점이 발생하지 않아야 한다. 그러한 시나리오에서 선점이 발생하면, 이슈를 올리기 바란다.
파드가 축출되었지만, 선점자는 스케줄링되지 않음
파드가 축출되면, 요청된 정상적인 종료
기간(기본적으로 30초)이 주어진다. 이 기간 내에 대상 파드가
종료되지 않으면, 강제 종료된다. 모든 피해자 파드가 사라지면,
선점자 파드를 스케줄링할 수 있다.
선점자 파드가 피해자 파드가 없어지기를 기다리는 동안, 동일한 노드에
적합한 우선순위가 높은 파드가 생성될 수 있다. 이 경우, 스케줄러는
선점자 대신 우선순위가 높은 파드를 스케줄링한다.
이것은 예상된 동작이다. 우선순위가 높은 파드는 우선순위가 낮은 파드를
대체해야 한다.
우선순위가 높은 파드는 우선순위가 낮은 파드보다 우선함
스케줄러가 보류 중인 파드를 실행할 수 있는 노드를 찾으려고 한다. 노드를 찾지
못하면, 스케줄러는 임의의 노드에서 우선순위가 낮은 파드를 제거하여
보류 중인 파드를 위한 공간을 만든다.
우선순위가 낮은 파드가 있는 노드가 보류 중인 파드를 실행할 수 없는 경우, 스케줄러는
선점을 위해 우선순위가 높은 다른 노드(다른 노드의 파드와 비교)를
선택할 수 있다. 피해자 파드는 여전히 선점자 파드보다 우선순위가
낮아야 한다.
선점할 수 있는 여러 노드가 있는 경우, 스케줄러는
우선순위가 가장 낮은 파드 세트를 가진 노드를 선택하려고 한다. 그러나,
이러한 파드가 위반될 PodDisruptionBudget을 가지고 있고 축출된 경우
스케줄러는 우선순위가 높은 파드를 가진 다른 노드를 선택할 수 있다.
선점을 위해 여러 개의 노드가 존재하고 위의 시나리오 중 어느 것도 적용되지 않는 경우,
스케줄러는 우선순위가 가장 낮은 노드를 선택한다.
파드 우선순위와 서비스 품질 간의 상호 작용
파드 우선순위와 QoS 클래스는
상호 작용이 거의 없고 QoS 클래스를 기반으로 파드 우선순위를 설정하는 데 대한
기본 제한이 없는 두 개의 직교(orthogonal) 기능이다. 스케줄러의
선점 로직은 선점 대상을 선택할 때 QoS를 고려하지 않는다.
선점은 파드 우선순위를 고려하고 우선순위가 가장 낮은 대상 세트를
선택하려고 한다. 우선순위가 가장 높은 파드는 스케줄러가
선점자 파드를 스케줄링할 수 없거나 우선순위가 가장 낮은 파드가
PodDisruptionBudget 으로 보호되는 경우에만, 우선순위가 가장 낮은 파드를
축출 대상으로 고려한다.
QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는
kubelet 리소스 부족 축출이다.
kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라,
파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해
먼저 축출 대상 파드의 순위를 매긴다.
더 자세한 내용은
엔드유저 파드 축출을
참조한다.
kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우
파드를 축출하지 않는다. 우선순위가 낮은 파드가 요청을
초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가
더 높은 다른 파드가 축출될 수 있다.
사용자는 kubectl, 클라이언트 라이브러리
또는 REST 요청을 통해
API에 접근한다.
사용자와 쿠버네티스 서비스 어카운트 모두 API에 접근할 수 있다.
요청이 API에 도달하면,
다음 다이어그램에 설명된 몇 가지 단계를 거친다.
전송 보안
일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다.
API 서버는 인증서를 제시한다.
이 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 $USER/.kube/config는
API 서버의 인증서에 대한 루트 인증서를 포함하며,
시스템 기본 루트 인증서 대신 사용된다.
kube-up.sh을 사용하여 클러스터를 직접 생성할 때
이 인증서는 일반적으로 $USER/.kube/config에 자동으로 기록된다.
클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
인증
TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다.
이는 다이어그램에 1단계로 표시되어 있다.
클러스터 생성 스크립트 또는 클러스터 관리자는
API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
인증기는 여기에서 더 자세히 서술한다.
인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.
인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
여러 개의 인증 모듈을 지정할 수 있으며,
이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.
GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.
요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다.
이 외에는 사용자가 특정 username으로 인증되며,
이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다.
일부 인증기는 사용자 그룹 관리 기능을 제공하는 반면,
이외의 인증기는 그렇지 않다.
쿠버네티스는 접근 제어 결정과 요청 기록 시 usernames를 사용하지만,
user 오브젝트를 가지고 있지 않고 usernames 나 기타 사용자 정보를
오브젝트 저장소에 저장하지도 않는다.
인가
특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다. 이는 다이어그램에 2단계로 표시되어 있다.
요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다. 기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우 요청이 인가된다.
예를 들어 Bob이 아래와 같은 정책을 가지고 있다면 projectCaribou 네임스페이스에서만 파드를 읽을 수 있다.
Bob이 projectCaribou 네임스페이스에 있는 오브젝트에 쓰기(create 또는 update) 요청을 하면 그의 인가는 거부된다. 만약 Bob이 projectFish처럼 다른 네임스페이스의 오브젝트 읽기(get) 요청을 하면 그의 인가는 거부된다.
쿠버네티스 인가는 공통 REST 속성을 사용하여 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 상호 작용할 것을 요구한다. 이러한 제어 시스템은 쿠버네티스 API 이외의 다른 API와 상호작용할 수 있으므로 REST 형식을 사용하는 것이 중요하다.
쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).
인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 인가 개요를 참조한다.
어드미션 제어
어드미션 제어 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이다.
인가 모듈에서 사용할 수 있는 속성 외에도
어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.
어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다.
어드미션 컨트롤러는 단순히 오브젝트를 읽는 요청에는 작동하지 않는다.
여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.
이는 다이어그램에 3단계로 표시되어 있다.
인증 및 인가 모듈과 달리,
어드미션 제어 모듈이 거부되면 요청은 즉시 거부된다.
어드미션 제어 모듈은 오브젝트를 거부하는 것 외에도
필드의 복잡한 기본값을 설정할 수 있다.
요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후
오브젝트 저장소에 기록(4단계)된다.
API 서버 포트와 IP
이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
기본적으로, 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
로컬호스트 포트:
테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소
(스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
TLS가 없다.
기본 포트는 8080이며, --insecure-port 플래그를 사용하여 변경한다.
기본 IP는 로컬호스트(localhost)이며, --insecure-bind-address 플래그를 사용하여 변경한다.
요청이 인증 및 인가 모듈을 우회한다.
요청이 어드미션 제어 모듈(들)에 의해 처리된다.
호스트 접근 요구로부터 보호를 받는다.
보안 포트:
가능한 항상 사용하는 것이 좋다.
TLS를 사용한다. --tls-cert-file 플래그로 인증서를 지정하고 --tls-private-key-file 플래그로 키를 지정한다.
기본 포트는 6443이며, --secure-port 플래그를 사용하여 변경한다.
기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, --bind-address 플래그를 사용하여 변경한다.
요청이 인증 및 인가 모듈에 의해 처리된다.
요청이 어드미션 제어 모듈(들)에 의해 처리된다.
인증 및 인가 모듈을 실행한다.
GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 kube-up.sh로 클러스터를 생성하면
API 서버는 포트 443에서 서비스한다.
GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
이외에 클러스터 설정 방법은 다양하다.
3.8.2 - 클라우드 네이티브 보안 개요
이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다.
경고: 이 컨테이너 보안 모델은 입증된 정보 보안 정책이 아닌 제안 사항을 제공한다.
클라우드 네이티브 보안의 4C
보안은 계층으로 생각할 수 있다. 클라우드 네이티브 보안의 4C는 클라우드(Cloud),
클러스터(Cluster), 컨테이너(Container)와 코드(Code)이다.
참고: 이 계층화된 접근 방식은 보안에 대한 심층 방어
컴퓨팅 접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로
널리 알려져 있다.
클라우드 네이티브 보안의 4C
클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 한다.
코드 계층은 강력한 기본(클라우드, 클러스터, 컨테이너) 보안 계층의 이점을 제공한다.
코드 수준에서 보안을 처리하여 기본 계층의 열악한 보안 표준을
보호할 수 없다.
클라우드
여러 면에서 클라우드(또는 공동 위치 서버, 또는 기업의 데이터 센터)는 쿠버네티스 클러스터 구성을 위한
신뢰 컴퓨팅 기반(trusted computing base)
이다. 클라우드 계층이 취약하거나 취약한 방식으로
구성된 경우 이 기반 위에서 구축된 구성 요소가 안전하다는
보장은 없다. 각 클라우드 공급자는 해당 환경에서 워크로드를 안전하게 실행하기
위한 보안 권장 사항을 제시한다.
클라우드 공급자 보안
자신의 하드웨어 또는 다른 클라우드 공급자에서 쿠버네티스 클러스터를 실행 중인 경우,
보안 모범 사례는 설명서를 참고한다.
다음은 인기있는 클라우드 공급자의 보안 문서 중 일부에 대한 링크이다.
쿠버네티스 컨트롤 플레인에 대한 모든 접근은 인터넷에서 공개적으로 허용되지 않으며 클러스터 관리에 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록에 의해 제어된다.
노드에 대한 네트워크 접근(노드)
지정된 포트의 컨트롤 플레인에서 만 (네트워크 접근 제어 목록을 통한) 연결을 허용하고 NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 노드를 구성해야 한다. 가능하면 이러한 노드가 공용 인터넷에 완전히 노출되어서는 안된다.
클라우드 공급자 API에 대한 쿠버네티스 접근
각 클라우드 공급자는 쿠버네티스 컨트롤 플레인 및 노드에 서로 다른 권한 집합을 부여해야 한다. 관리해야하는 리소스에 대해 최소 권한의 원칙을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. Kops 설명서는 IAM 정책 및 역할에 대한 정보를 제공한다.
etcd에 대한 접근
etcd(쿠버네티스의 데이터 저장소)에 대한 접근은 컨트롤 플레인으로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 내용은 etcd 문서에서 확인할 수 있다.
etcd 암호화
가능한 한 모든 드라이브를 암호화하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다.
클러스터
쿠버네티스 보안에는 다음의 두 가지 영역이 있다.
설정 가능한 클러스터 컴포넌트의 보안
클러스터에서 실행되는 애플리케이션의 보안
클러스터의 컴포넌트
우발적이거나 악의적인 접근으로부터 클러스터를 보호하고,
모범 사례에 대한 정보를 채택하기 위해서는
클러스터 보안에 대한 조언을 읽고 따른다.
클러스터 내 컴포넌트(애플리케이션)
애플리케이션의 공격 영역에 따라, 보안의 특정 측면에
중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와
리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우,
서비스 B의 리소스를 제한하지 않으면
서비스 A가 손상될 위험이 높다. 다음은 쿠버네티스에서
실행되는 워크로드를 보호하기 위한 보안 문제 및 권장 사항이 나와 있는 표이다.
애플리케이션 코드는 가장 많은 제어를 할 수 있는 주요 공격 영역 중 하나이다.
애플리케이션 코드 보안은 쿠버네티스 보안 주제를 벗어나지만,
애플리케이션 코드를 보호하기 위한 권장 사항은 다음과 같다.
코드 보안
코드 보안
코드에서 고려할 영역
추천
TLS를 통한 접근
코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 mTLS를 통해 수행할 수 있다.
통신 포트 범위 제한
이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다.
타사 종속성 보안
애플리케이션의 타사 라이브러리를 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다.
쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 파드가 노드와 일치하는지 확인하는 것을 말한다. 축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 장애로 처리하는 프로세스이다.
3.9.1 - 쿠버네티스 스케줄러
쿠버네티스에서 스케줄링 은 Kubelet이
파드를 실행할 수 있도록 파드가
노드에 적합한지 확인하는 것을 말한다.
스케줄링 개요
스케줄러는 노드가 할당되지 않은 새로 생성된 파드를 감시한다.
스케줄러가 발견한 모든 파드에 대해 스케줄러는 해당 파드가 실행될
최상의 노드를 찾는 책임을 진다. 스케줄러는
아래 설명된 스케줄링 원칙을 고려하여 이 배치 결정을
하게 된다.
파드가 특정 노드에 배치되는 이유를 이해하려고 하거나
사용자 정의된 스케줄러를 직접 구현하려는 경우 이
페이지를 통해서 스케줄링에 대해 배울 수 있을 것이다.
kube-scheduler
kube-scheduler는
쿠버네티스의 기본 스케줄러이며 컨트롤 플레인의
일부로 실행된다.
kube-scheduler는 원하거나 필요에 따라 자체 스케줄링 컴포넌트를
만들고 대신 사용할 수 있도록 설계되었다.
새로 생성된 모든 파드 또는 예약되지 않은 다른 파드에 대해 kube-scheduler는
실행할 최적의 노드를 선택한다. 그러나 파드의 모든 컨테이너에는
리소스에 대한 요구사항이 다르며 모든 파드에도
요구사항이 다르다. 따라서 기존 노드들은
특정 스케줄링 요구사항에 따라 필터링 되어야 한다.
클러스터에서 파드에 대한 스케줄링 요구사항을 충족하는 노드를
실행 가능한(feasible) 노드라고 한다. 적합한 노드가 없으면 스케줄러가
배치할 수 있을 때까지 파드가 스케줄 되지 않은 상태로 유지된다.
스케줄러는 파드가 실행 가능한 노드를 찾은 다음 실행 가능한 노드의
점수를 측정하는 기능 셋을 수행하고 실행 가능한 노드 중에서 가장 높은 점수를
가진 노드를 선택하여 파드를 실행한다. 그런 다음 스케줄러는
바인딩 이라는 프로세스에서 이 결정에 대해 API 서버에 알린다.
스케줄링 결정을 위해 고려해야 할 요소에는
개별 및 집단 리소스 요구사항, 하드웨어 / 소프트웨어 /
정책 제한조건, 어피니티 및 안티-어피니티 명세, 데이터
지역성(data locality), 워크로드 간 간섭 등이 포함된다.
kube-scheduler에서 노드 선택
kube-scheduler는 2단계 작업에서 파드에 대한 노드를 선택한다.
필터링
스코어링(scoring)
필터링 단계는 파드를 스케줄링 할 수 있는 노드 셋을
찾는다. 예를 들어 PodFitsResources 필터는
후보 노드가 파드의 특정 리소스 요청을 충족시키기에 충분한 가용 리소스가
있는지 확인한다. 이 단계 다음에 노드 목록에는 적합한 노드들이
포함된다. 하나 이상의 노드가 포함된 경우가 종종 있을 것이다. 목록이 비어 있으면
해당 파드는 (아직) 스케줄링 될 수 없다.
스코어링 단계에서 스케줄러는 목록에 남아있는 노드의 순위를 지정하여
가장 적합한 파드 배치를 선택한다. 스케줄러는 사용 중인 스코어링 규칙에 따라
이 점수를 기준으로 필터링에서 통과된 각 노드에 대해 점수를 지정한다.
마지막으로 kube-scheduler는 파드를 순위가 가장 높은 노드에 할당한다.
점수가 같은 노드가 두 개 이상인 경우 kube-scheduler는
이들 중 하나를 임의로 선택한다.
스케줄러의 필터링 및 스코어링 동작을 구성하는 데 지원되는 두 가지
방법이 있다.
스케줄링 정책을 사용하면 필터링을 위한 단정(Predicates) 및 스코어링을 위한 우선순위(Priorities) 를 구성할 수 있다.
스케줄링 프로파일을 사용하면 QueueSort, Filter, Score, Bind, Reserve, Permit 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
특정한 노드(들) 집합에서만 동작하도록
파드를 제한할 수 있다.
이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두
레이블 셀렉터를 사용하여 선택을 용이하게 한다.
보통 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록
노드 간에 파드를 분배하는 등)를 수행하기에 이러한 제약 조건은 필요하지 않지만
간혹 파드가 배포할 노드를 제어해야 하는 경우가 있다.
예를 들어 SSD가 장착된 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서
많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다.
노드 셀렉터(nodeSelector)
nodeSelector 는 가장 간단하고 권장되는 노드 선택 제약 조건의 형태이다.
nodeSelector 는 PodSpec의 필드이다. 이는 키-값 쌍의 매핑으로 지정한다. 파드가 노드에서 동작할 수 있으려면,
노드는 키-값의 쌍으로 표시되는 레이블을 각자 가지고 있어야 한다(이는 추가 레이블을 가지고 있을 수 있다).
일반적으로 하나의 키-값 쌍이 사용된다.
nodeSelector 를 어떻게 사용하는지 예시를 통해 알아보도록 하자.
0 단계: 사전 준비
이 예시는 쿠버네티스 파드에 대한 기본적인 이해를 하고 있고 쿠버네티스 클러스터가 설정되어 있다고 가정한다.
1 단계: 노드에 레이블 붙이기
kubectl get nodes 를 실행해서 클러스터 노드 이름을 가져온다. 이 중에 레이블을 추가하기 원하는 것 하나를 선택한 다음에 kubectl label nodes <노드 이름> <레이블 키>=<레이블 값> 을 실행해서 선택한 노드에 레이블을 추가한다. 예를 들어 노드의 이름이 'kubernetes-foo-node-1.c.a-robinson.internal' 이고, 원하는 레이블이 'disktype=ssd' 라면, kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd 를 실행한다.
kubectl get nodes --show-labels 를 다시 실행해서 노드가 현재 가진 레이블을 확인하여, 이 작업을 검증할 수 있다. 또한 kubectl describe node "노드 이름" 을 사용해서 노드에 주어진 레이블의 전체 목록을 확인할 수 있다.
2 단계: 파드 설정에 nodeSelector 필드 추가하기
실행하고자 하는 파드의 설정 파일을 가져오고, 이처럼 nodeSelector 섹션을 추가한다. 예를 들어 이것이 파드 설정이라면,
그런 다음에 kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml 을
실행하면, 레이블이 붙여진 노드에 파드가 스케줄된다.
kubectl get pods -o wide 를 실행해서 파드가 할당된
"NODE" 를 보면 작동하는지 검증할 수 있다.
참고: 이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다.
예를 들어 kubernetes.io/hostname 은 어떤 환경에서는 노드 이름과 같지만,
다른 환경에서는 다른 값일 수 있다.
노드 격리(isolation)/제한(restriction)
노드 오브젝트에 레이블을 추가하면 파드가 특정 노드 또는 노드 그룹을 목표 대상으로 할 수 있게 된다.
이는 특정 파드가 어떤 격리, 보안, 또는 규제 속성이 있는 노드에서만 실행되도록 사용할 수 있다.
이 목적으로 레이블을 사용하는 경우, 노드에서 kubelet 프로세스로 수정할 수 없는 레이블 키를 선택하는 것을 권장한다.
이렇게 하면 손상된 노드가 해당 kubelet 자격 증명을 사용해서 해당 레이블을 자체 노드 오브젝트에 설정하고,
스케줄러가 손상된 노드로 워크로드를 스케줄 하는 것을 방지할 수 있다.
NodeRestriction 어드미션 플러그인은 kubelet이 node-restriction.kubernetes.io/ 접두사로 레이블을 설정 또는 수정하지 못하게 한다.
노드 격리에 해당 레이블 접두사를 사용하려면 다음과 같이 한다.
노드 오브젝트의 node-restriction.kubernetes.io/ 접두사 아래에 레이블을 추가하고, 해당 레이블을 노드 셀렉터에서 사용한다.
예를 들어, example.com.node-restriction.kubernetes.io/fips=true 또는 example.com.node-restriction.kubernetes.io/pci-dss=true 이다.
어피니티(affinity)와 안티-어피니티(anti-affinity)
nodeSelector 는 파드를 특정 레이블이 있는 노드로 제한하는 매우 간단한 방법을 제공한다.
어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 주요 개선 사항은 다음과 같다.
어피니티/안티-어피니티 언어가 더 표현적이다. 언어는 논리 연산자인 AND 연산으로 작성된
정확한 매칭 항목 이외에 더 많은 매칭 규칙을 제공한다.
규칙이 엄격한 요구 사항이 아니라 "유연한(soft)"/"선호(preference)" 규칙을 나타낼 수 있기에 스케줄러가 규칙을 만족할 수 없더라도,
파드가 계속 스케줄되도록 한다.
노드 자체에 레이블을 붙이기보다는 노드(또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 제한할 수 있다.
이를 통해 어떤 파드가 함께 위치할 수 있는지와 없는지에 대한 규칙을 적용할 수 있다.
어피니티 기능은 "노드 어피니티" 와 "파드 간 어피니티/안티-어피니티" 두 종류의 어피니티로 구성된다.
노드 어피니티는 기존 nodeSelector 와 비슷하지만(그러나 위에서 나열된 첫째와 두 번째 이점이 있다.),
파드 간 어피니티/안티-어피니티는 위에서 나열된 세번째 항목에 설명된 대로
노드 레이블이 아닌 파드 레이블에 대해 제한되고 위에서 나열된 첫 번째와 두 번째 속성을 가진다.
노드 어피니티
노드 어피니티는 개념적으로 nodeSelector 와 비슷하다 -- 이는 노드의 레이블을 기반으로 파드를
스케줄할 수 있는 노드를 제한할 수 있다.
여기에 현재 requiredDuringSchedulingIgnoredDuringExecution 와 preferredDuringSchedulingIgnoredDuringExecution 로 부르는
두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 반드시
규칙을 만족해야 하는 것(nodeSelector 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고,
후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 선호(preferences) 를 지정한다는 점에서
이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다.
이름의 "IgnoredDuringExecution" 부분은 nodeSelector 작동 방식과 유사하게 노드의
레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서
동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는
점을 제외하고는 preferredDuringSchedulingIgnoredDuringExecution 와 동일한 requiredDuringSchedulingIgnoredDuringExecution 를 제공할 계획이다.
따라서 requiredDuringSchedulingIgnoredDuringExecution 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이
될 수 있고, preferredDuringSchedulingIgnoredDuringExecution 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고
하지만, 불가능하다면 다른 곳에서 일부를 실행하도록 허용"이 있을 것이다.
이 노드 어피니티 규칙은 키가 kubernetes.io/e2e-az-name 이고 값이 e2e-az1 또는 e2e-az2 인
레이블이 있는 노드에만 파드를 배치할 수 있다고 말한다. 또한, 이 기준을 충족하는 노드들
중에서 키가 another-node-label-key 이고 값이 another-node-label-value 인 레이블이 있는 노드를
선호하도록 한다.
예시에서 연산자 In 이 사용되고 있는 것을 볼 수 있다. 새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. In, NotIn, Exists, DoesNotExist, Gt, Lt.
NotIn 과 DoesNotExist 를 사용해서 안티-어피니티를 수행하거나,
특정 노드에서 파드를 쫓아내는 노드 테인트(taint)를 설정할 수 있다.
nodeSelector 와 nodeAffinity 를 모두 지정한다면 파드가 후보 노드에 스케줄되기 위해서는
둘 다 반드시 만족해야 한다.
nodeAffinity 유형과 연관된 nodeSelectorTerms 를 지정하면, nodeSelectorTerms 중 하나라도 만족시키는 노드에 파드가 스케줄된다.
nodeSelectorTerms 와 연관된 여러 matchExpressions 를 지정하면, 파드는 matchExpressions 를 모두 만족하는 노드에만 스케줄된다.
파드가 스케줄된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다.
preferredDuringSchedulingIgnoredDuringExecution 의 weight 필드의 범위는 1-100이다. 모든 스케줄링 요구 사항 (리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해 스케줄러는 이 필드의 요소들을 반복해서 합계를 계산하고 노드가 MatchExpressions 에 일치하는 경우 합계에 "가중치(weight)"를 추가한다. 이후에 이 점수는 노드에 대한 다른 우선순위 함수의 점수와 합쳐진다. 전체 점수가 가장 높은 노드를 가장 선호한다.
스케줄링 프로파일당 노드 어피니티
FEATURE STATE:Kubernetes v1.20 [beta]
여러 스케줄링 프로파일을 구성할 때
노드 어피니티가 있는 프로파일을 연결할 수 있는데, 이는 프로파일이 특정 노드 집합에만 적용되는 경우 유용하다.
이렇게 하려면 스케줄러 구성에 있는
NodeAffinity 플러그인의 인수에 addedAffinity를 추가한다. 예를 들면
addedAffinity는 .spec.schedulerName을 foo-scheduler로 설정하는 모든 파드에 적용되며
PodSpec에 지정된 NodeAffinity도 적용된다.
즉, 파드를 매칭시키려면, 노드가 addedAffinity와 파드의 .spec.NodeAffinity를 충족해야 한다.
addedAffinity는 엔드 유저에게 표시되지 않으므로, 예상치 못한 동작이 일어날 수 있다. 프로파일의
스케줄러 이름과 명확한 상관 관계가 있는 노드 레이블을 사용하는 것이 좋다.
참고:데몬셋용 파드를 생성하는 데몬셋 컨트롤러는
스케줄링 프로파일을 인식하지 못한다.
따라서 addedAffinity없이 default-scheduler와 같은 스케줄러 프로파일을 유지하는 것이 좋다. 그런 다음 데몬셋의 파드 템플릿이 스케줄러 이름을 사용해야 한다.
그렇지 않으면, 데몬셋 컨트롤러에 의해 생성된 일부 파드가 스케줄되지 않은 상태로 유지될 수 있다.
파드간 어피니티와 안티-어피니티
파드간 어피니티와 안티-어피니티를 사용하면 노드의 레이블을 기반으로 하지 않고, 노드에서 이미 실행 중인 파드 레이블을 기반으로
파드가 스케줄될 수 있는 노드를 제한할 수 있다. 규칙은 "X가 규칙 Y를 충족하는 하나 이상의 파드를 이미 실행중인 경우
이 파드는 X에서 실행해야 한다(또는 안티-어피니티가 없는 경우에는 동작하면 안된다)"는 형태이다. Y는
선택적으로 연관된 네임스페이스 목록을 가진 LabelSelector로 표현된다. 노드와는 다르게 파드는 네임스페이스이기에
(그리고 따라서 파드의 레이블은 암암리에 네임스페이스이다) 파드 레이블위의 레이블 셀렉터는 반드시
셀렉터가 적용될 네임스페이스를 지정해야만 한다. 개념적으로 X는 노드, 랙,
클라우드 공급자 영역, 클라우드 공급자 지역 등과 같은 토폴로지 도메인이다. 시스템이 이런 토폴로지
도메인을 나타내는 데 사용하는 노드 레이블 키인 topologyKey 를 사용하여 이를 표현한다.
예: 넘어가기 전에: 빌트인 노드 레이블 섹션 위에 나열된 레이블 키를 본다.
참고: 파드간 어피니티와 안티-어피니티에는 상당한 양의 프로세싱이 필요하기에
대규모 클러스터에서는 스케줄링 속도가 크게 느려질 수 있다.
수백 개의 노드를 넘어가는 클러스터에서 이를 사용하는 것은 추천하지 않는다.
참고: 파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다. 즉, 클러스터의 모든 노드는 topologyKey 와 매칭되는 적절한 레이블을 가지고 있어야 한다. 일부 또는 모든 노드에 지정된 topologyKey 레이블이 없는 경우에는 의도하지 않은 동작이 발생할 수 있다.
노드 어피니티와 마찬가지로 현재 파드 어피니티와 안티-어피니티로 부르는 "엄격함" 대 "유연함"의 요구사항을 나타내는 requiredDuringSchedulingIgnoredDuringExecution 와
preferredDuringSchedulingIgnoredDuringExecution 두 가지 종류가 있다.
앞의 노드 어피니티 섹션의 설명을 본다.
requiredDuringSchedulingIgnoredDuringExecution 어피니티의 예시는
"서로 많은 통신을 하기 때문에 서비스 A와 서비스 B를 같은 영역에 함께 위치시키는 것"이고,
preferredDuringSchedulingIgnoredDuringExecution 안티-어피니티의 예시는 "서비스를 여러 영역에 걸쳐서 분배하는 것"이다
(엄격한 요구사항은 영역보다 파드가 더 많을 수 있기 때문에 엄격한 요구사항은 의미가 없다).
파드간 어피니티는 PodSpec에서 affinity 필드 중 podAffinity 필드로 지정한다.
그리고 파드간 안티-어피니티는 PodSpec에서 affinity 필드 중 podAntiAffinity 필드로 지정한다.
이 파드의 어피니티는 하나의 파드 어피니티 규칙과 하나의 파드 안티-어피니티 규칙을 정의한다.
이 예시에서 podAffinity 는 requiredDuringSchedulingIgnoredDuringExecution 이고 podAntiAffinity 는
preferredDuringSchedulingIgnoredDuringExecution 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값
"S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다.
(보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키
topology.kubernetes.io/zone 와 값 V인 노드가 최소 하나 이상 있고,
노드 N이 키 topology.kubernetes.io/zone 와
일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.)
파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와
동일한 영역의 노드에 스케줄되지 않는다.
디자인 문서를 통해
requiredDuringSchedulingIgnoredDuringExecution 와 preferredDuringSchedulingIgnoredDuringExecution 의
파드 어피니티와 안티-어피니티에 대한 많은 예시를 맛볼 수 있다.
파드 어피니티와 안티-어피니티의 적합한 연산자는 In, NotIn, Exists, DoesNotExist 이다.
원칙적으로, topologyKey 는 적법한 어느 레이블-키도 될 수 있다.
하지만, 성능과 보안상의 이유로 topologyKey에는 몇 가지 제약조건이 있다.
파드 어피니티에서 requiredDuringSchedulingIgnoredDuringExecution 와 preferredDuringSchedulingIgnoredDuringExecution 는
topologyKey 의 빈 값을 허용하지 않는다.
파드 안티-어피니티에서도 requiredDuringSchedulingIgnoredDuringExecution 와 preferredDuringSchedulingIgnoredDuringExecution 는
topologyKey 의 빈 값을 허용하지 않는다.
requiredDuringSchedulingIgnoredDuringExecution 파드 안티-어피니티에서 topologyKey 를 kubernetes.io/hostname 로 제한하기 위해 어드미션 컨트롤러 LimitPodHardAntiAffinityTopology 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 이를 비활성화해야 한다.
위의 경우를 제외하고, topologyKey 는 적법한 어느 레이블-키도 가능하다.
labelSelector 와 topologyKey 외에도 labelSelector 와 일치해야 하는 네임스페이스 목록 namespaces 를
선택적으로 지정할 수 있다(이것은 labelSelector 와 topologyKey 와 같은 수준의 정의이다).
생략되어있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.
파드를 노드에 스케줄하려면 requiredDuringSchedulingIgnoredDuringExecution 어피니티와 안티-어피니티와
연관된 matchExpressions 가 모두 충족되어야 한다.
더 실용적인 유스케이스
파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은
상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다. 워크로드 집합이 동일한 노드와 같이
동일하게 정의된 토폴로지와 같은 위치에 배치되도록 쉽게 구성할 수 있다.
항상 같은 노드에 위치시키기
세 개의 노드가 있는 클러스터에서 웹 애플리케이션에는 redis와 같은 인-메모리 캐시가 있다. 웹 서버가 가능한 캐시와 함께 위치하기를 원한다.
다음은 세 개의 레플리카와 셀렉터 레이블이 app=store 가 있는 간단한 redis 디플로이먼트의 yaml 스니펫이다. 디플로이먼트에는 스케줄러가 단일 노드에서 레플리카를 함께 배치하지 않도록 PodAntiAffinity 가 구성되어 있다.
아래 yaml 스니펫의 웹서버 디플로이먼트는 podAntiAffinity 와 podAffinity 설정을 가지고 있다. 이렇게 하면 스케줄러에 모든 레플리카는 셀렉터 레이블이 app=store 인 파드와 함께 위치해야 한다. 또한 각 웹 서버 레플리카가 단일 노드의 같은 위치에 있지 않도록 한다.
위의 예시에서 topologyKey:"kubernetes.io/hostname" 과 함께 PodAntiAffinity 규칙을 사용해서
두 개의 인스터스가 동일한 호스트에 있지 않도록 redis 클러스터를 배포한다.
같은 기술을 사용해서 고 가용성을 위해 안티-어피니티로 구성된 스테이트풀셋의 예시는
ZooKeeper 튜토리얼을 본다.
nodeName
nodeName 은 가장 간단한 형태의 노트 선택 제약 조건이지만,
한계로 인해 일반적으로는 사용하지 않는다.
nodeName 은 PodSpec의 필드이다. 만약 비어있지 않으면, 스케줄러는
파드를 무시하고 명명된 노드에서 실행 중인 kubelet이
파드를 실행하려고 한다. 따라서 만약 PodSpec에 nodeName 가
제공된 경우, 노드 선텍을 위해 위의 방법보다 우선한다.
nodeName 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다.
만약 명명된 노드가 없으면, 파드가 실행되지 않고
따라서 자동으로 삭제될 수 있다.
만약 명명된 노드에 파드를 수용할 수 있는
리소스가 없는 경우 파드가 실패하고, 그 이유는 다음과 같이 표시된다.
예: OutOfmemory 또는 OutOfcpu.
파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다.
토폴로지 매니저는
노드 수준의 리소스 할당 결정에 참여할 수 있다.
3.9.3 - 파드 오버헤드
FEATURE STATE:Kubernetes v1.18 [beta]
노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다.
이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다.
파드 오버헤드 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해
소비되는 리소스를 계산하는 기능이다.
쿠버네티스에서 파드의 오버헤드는 파드의
런타임클래스 와 관련된 오버헤드에 따라
어드미션
이 수행될 때 지정된다.
파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에
파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나
파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다.
파드 오버헤드 활성화하기
기능 활성화를 위해 클러스터에서
PodOverhead기능 게이트가 활성화되어 있고(1.18 버전에서는 기본적으로 활성화),
overhead 필드를 정의하는 RuntimeClass 가 사용되고 있는지 확인해야 한다.
사용 예제
파드 오버헤드 기능을 사용하기 위하여, overhead 필드를 정의하는 런타임클래스가 필요하다.
예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는
가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다.
어드미션 수행 시에, 어드미션 컨트롤러는
런타임클래스에 기술된 overhead 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면,
파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가
overhead 를 포함하도록 변경한다.
런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다.
kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
명령 실행 결과는 다음과 같다.
map[cpu:250m memory:120Mi]
만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는
overhead 필드도 추가된다.
kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 overhead 와
해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는
리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다.
일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 cgroup을 생성한다.
기본 컨테이너 런타임이 만들어내는 컨테이너들은 이 파드 안에 존재한다.
만약 각 컨테이너에 대하여 QoS가 보장되었거나 향상이 가능하도록 QoS 의 리소스 상한 제한이 걸려있으면,
kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의
cgroup 의 상한선을 설정한다. 이 상한선은 컨테이너 리소스 상한과 PodSpec에
정의된 overhead 의 합에 기반한다.
CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, kubelet은 PodSpec에 정의된 overhead 에 컨테이너의
리소스 요청의 합을 더한 값을 cpu.shares 로 설정한다.
다음의 예제를 참고하여, 워크로드에 대하여 컨테이너의 리소스 요청을 확인하자.
kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 파드의 오버헤드를 포함한다.
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m
파드 cgroup 상한 확인하기
워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, crictl은 노드에서 사용되며,
CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다.
파드의 오버헤드 동작을 보여주는 좋은 예이며,
사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다.
먼저 특정 노드에서 파드의 식별자를 확인해 보자.
# 파드가 스케줄 된 노드에서 이것을 실행POD_ID="$(sudo crictl pods --name test-pod -q)"
여기에서, 파드의 cgroup 경로를 확인할 수 있다.
# 파드가 스케줄 된 노드에서 이것을 실행
sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
명령의 결과로 나온 cgroup 경로는 파드의 pause 컨테이너를 포함한다. 파드 레벨의 cgroup은 하나의 디렉터리이다.
아래의 특정한 경우에, 파드 cgroup 경로는 kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2 이다. 메모리의 파드 레벨 cgroup 설정을 확인하자.
# 파드가 스케줄 된 노드에서 이것을 실행.# 또한 사용자의 파드에 할당된 cgroup 이름에 맞춰 해당 이름을 수정.
cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
예상대로 320 MiB 이다.
335544320
관찰성
kube_pod_overhead 항목은 kube-state-metrics
에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고,
정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다.
이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다.
그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다.
kube-scheduler는 RequestedToCapacityRatioResourceAllocation
우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록
구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라
kube-scheduler를 미세 조정할 수 있다.
RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기
쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를
통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
RequestedToCapacityRatioResourceAllocation 우선 순위 기능의
동작은 requestedToCapacityRatioArguments라는
구성 옵션으로 제어할 수 있다. 이 인수는 shape와 resources
두 개의 파라미터로 구성된다. shape 파라미터는 사용자가 utilization과
score 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을
조정할 수 있게 한다. resources 파라미터는 점수를 매길 때 고려할
리소스의 name 과 각 리소스의 가중치를 지정하는 weight 로
구성된다.
다음은 확장된 리소스 intel.com/foo 와 intel.com/bar 에 대한
requestedToCapacityRatioArguments 를 빈 패킹 동작으로
설정하는 구성의 예시이다.
톨러레이션은 키가 동일하고 이펙트가 동일한 경우, 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다.
operator 가 Exists 인 경우(이 경우 value 를 지정하지 않아야 함), 또는
operator 는 Equal 이고 value 는 value 로 같다.
참고:
두 가지 특별한 경우가 있다.
operator Exists 가 있는 비어있는 key 는 모든 키, 값 및 이펙트와 일치하므로
모든 것이 톨러레이션 된다.
비어있는 effect 는 모든 이펙트를 키 key1 와 일치시킨다.
위의 예는 NoSchedule 의 effect 를 사용했다. 또는, PreferNoSchedule 의 effect 를 사용할 수 있다.
이것은 NoSchedule 의 "기본 설정(preference)" 또는 "소프트(soft)" 버전이다. 시스템은 노드의 테인트를 허용하지 않는
파드를 배치하지 않으려고 시도 하지만, 필요하지는 않다. 세 번째 종류의 effect 는
나중에 설명할 NoExecute 이다.
동일한 노드에 여러 테인트를, 동일한 파드에 여러 톨러레이션을 둘 수 있다.
쿠버네티스가 여러 테인트 및 톨러레이션을 처리하는 방식은 필터와 같다.
모든 노드의 테인트로 시작한 다음, 파드에 일치하는 톨러레이션이 있는 것을 무시한다.
무시되지 않은 나머지 테인트는 파드에 표시된 이펙트를 가진다. 특히,
NoSchedule 이펙트가 있는 무시되지 않은 테인트가 하나 이상 있으면 쿠버네티스는 해당 노드에
파드를 스케줄하지 않는다.
NoSchedule 이펙트가 있는 무시되지 않은 테인트가 없지만 PreferNoSchedule 이펙트가 있는
무시되지 않은 테인트가 하나 이상 있으면 쿠버네티스는 파드를 노드에 스케쥴하지 않으려고 시도 한다
NoExecute 이펙트가 있는 무시되지 않은 테인트가 하나 이상 있으면
파드가 노드에서 축출되고(노드에서 이미 실행 중인 경우), 노드에서
스케줄되지 않는다(아직 실행되지 않은 경우).
이 경우, 세 번째 테인트와 일치하는 톨러레이션이 없기 때문에, 파드는
노드에 스케줄 될 수 없다. 그러나 세 번째 테인트가 파드에서 용인되지 않는 세 가지 중
하나만 있기 때문에, 테인트가 추가될 때 노드에서 이미 실행 중인 경우,
파드는 계속 실행할 수 있다.
일반적으로, NoExecute 이펙트가 있는 테인트가 노드에 추가되면, 테인트를
용인하지 않는 파드는 즉시 축출되고, 테인트를 용인하는 파드는
축출되지 않는다. 그러나 NoExecute 이펙트가 있는 톨러레이션은
테인트가 추가된 후 파드가 노드에 바인딩된 시간을 지정하는
선택적 tolerationSeconds 필드를 지정할 수 있다. 예를 들어,
이것은 이 파드가 실행 중이고 일치하는 테인트가 노드에 추가되면,
파드는 3600초 동안 노드에 바인딩된 후, 축출된다는 것을 의미한다. 그 전에
테인트를 제거하면, 파드가 축출되지 않는다.
유스케이스 예시
테인트 및 톨러레이션은 파드를 노드에서 멀어지게 하거나 실행되지 않아야 하는
파드를 축출할 수 있는 유연한 방법이다. 유스케이스 중 일부는 다음과 같다.
전용 노드: 특정 사용자들이 독점적으로 사용하도록
노드 셋을 전용하려면, 해당 노드에 테인트를 추가(예:
kubectl taint nodes nodename dedicated=groupName:NoSchedule)한 다음 해당
톨러레이션을 그들의 파드에 추가할 수 있다(사용자 정의 [어드미션 컨트롤러]
(/docs/reference/access-authn-authz/admission-controllers/)를 작성하면 가장 쉽게 수행할 수 있음).
그런 다음 톨러레이션이 있는 파드는 테인트된(전용) 노드와
클러스터의 다른 노드를 사용할 수 있다. 노드를 특정 사용자들에게 전용으로 지정하고 그리고
그 사용자들이 전용 노드 만 사용하려면, 동일한 노드 셋에
테인트와 유사한 레이블을 추가해야 하고(예: dedicated=groupName),
어드미션 컨트롤러는 추가로 파드가 dedicated=groupName 으로 레이블이 지정된 노드에만
스케줄될 수 있도록 노드 어피니티를 추가해야 한다.
특별한 하드웨어가 있는 노드: 작은 서브셋의 노드에 특별한
하드웨어(예: GPU)가 있는 클러스터에서는, 특별한 하드웨어가 필요하지 않는 파드를
해당 노드에서 분리하여, 나중에 도착하는 특별한 하드웨어가 필요한 파드를 위한 공간을
남겨두는 것이 바람직하다. 이는 특별한 하드웨어가 있는
노드(예: kubectl taint nodes nodename special=true:NoSchedule 또는
kubectl taint nodes nodename special=true:PreferNoSchedule)에 테인트를 추가하고
특별한 하드웨어를 사용하는 파드에 해당 톨러레이션을 추가하여 수행할 수 있다. 전용 노드 유스케이스에서와 같이,
사용자 정의 어드미션 컨트롤러를
사용하여 톨러레이션를 적용하는 것이 가장 쉬운 방법이다.
예를 들어, 확장된
리소스를
사용하여 특별한 하드웨어를 나타내고, 확장된 리소스 이름으로
특별한 하드웨어 노드를 테인트시키고
ExtendedResourceToleration
어드미션 컨트롤러를 실행하는 것을 권장한다. 이제, 노드가 테인트되었으므로, 톨러레이션이 없는
파드는 스케줄되지 않는다. 그러나 확장된 리소스를 요청하는 파드를 제출하면,
ExtendedResourceToleration 어드미션 컨트롤러가
파드에 올바른 톨러레이션을 자동으로 추가하고 해당 파드는
특별한 하드웨어 노드에서 스케줄된다. 이렇게 하면 이러한 특별한 하드웨어 노드가
해당 하드웨어를 요청하는 파드가 전용으로 사용하며 파드에 톨러레이션을
수동으로 추가할 필요가 없다.
테인트 기반 축출: 노드 문제가 있을 때 파드별로
구성 가능한 축출 동작은 다음 섹션에서 설명한다.
테인트 기반 축출
FEATURE STATE:Kubernetes v1.18 [stable]
앞에서 우리는 노드에서 이미 실행 중인 파드에 영향을 주는 NoExecute 테인트 이펙트를
다음과 같이 언급했다.
테인트를 용인하지 않는 파드는 즉시 축출된다.
톨러레이션 명세에 tolerationSeconds 를 지정하지 않고
테인트를 용인하는 파드는 계속 바인딩된다.
tolerationSeconds 가 지정된 테인트를 용인하는 파드는 지정된
시간 동안 바인딩된 상태로 유지된다.
노드 컨트롤러는 특정 조건이 참일 때 자동으로
노드를 테인트시킨다. 다음은 빌트인 테인트이다.
node.kubernetes.io/not-ready: 노드가 준비되지 않았다. 이는 NodeCondition
Ready 가 "False"로 됨에 해당한다.
node.kubernetes.io/unreachable: 노드가 노드 컨트롤러에서 도달할 수 없다. 이는
NodeCondition Ready 가 "Unknown"로 됨에 해당한다.
node.kubernetes.io/out-of-disk: 노드에 디스크가 부족하다.
node.kubernetes.io/memory-pressure: 노드에 메모리 할당 압박이 있다.
node.kubernetes.io/disk-pressure: 노드에 디스크 할당 압박이 있다.
node.kubernetes.io/network-unavailable: 노드의 네트워크를 사용할 수 없다.
node.kubernetes.io/unschedulable: 노드를 스케줄할 수 없다.
node.cloudprovider.kubernetes.io/uninitialized: "외부" 클라우드 공급자로
kubelet을 시작하면, 이 테인트가 노드에서 사용 불가능으로 표시되도록
설정된다. 클라우드-컨트롤러-관리자의 컨트롤러가 이 노드를 초기화하면,
kubelet이 이 테인트를 제거한다.
노드가 축출될 경우, 노드 컨트롤러 또는 kubelet은 NoExecute 이펙트로 관련
테인트를 추가한다. 장애 상태가 정상으로 돌아오면 kubelet 또는 노드 컨트롤러가
관련 테인트를 제거할 수 있다.
참고: 콘트롤 플레인은 노드에 새 테인트를 추가하는 비율을 제한한다.
이 비율-제한은 많은 노드가 동시에 도달할 수 없을 때(예를 들어, 네트워크 중단으로)
트리거될 축출 개수를 관리한다.
이 기능을 tolerationSeconds 와 함께 사용하면, 파드에서
이러한 문제 중 하나 또는 둘 다가 있는 노드에 바인딩된 기간을 지정할 수 있다.
예를 들어, 로컬 상태가 많은 애플리케이션은 네트워크 분할의 장애에서
네트워크가 복구된 후에 파드가 축출되는 것을 피하기 위해
오랫동안 노드에 바인딩된 상태를 유지하려고 할 수 있다.
이 경우 파드가 사용하는 톨러레이션은 다음과 같다.
쿠버네티스는 사용자나 컨트롤러에서 명시적으로 설정하지 않았다면, 자동으로
node.kubernetes.io/not-ready 와 node.kubernetes.io/unreachable 에 대해
tolerationSeconds=300 으로
톨러레이션을 추가한다.
자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 감지된 후 5분 동안
파드가 노드에 바인딩된 상태를 유지함을 의미한다.
데몬셋 파드는 tolerationSeconds 가 없는
다음 테인트에 대해 NoExecute 톨러레이션를 가지고 생성된다.
node.kubernetes.io/unreachable
node.kubernetes.io/not-ready
이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다.
컨디션별 노드 테인트하기
노드 라이프사이클 컨트롤러는 NoSchedule 이펙트가 있는 노드 컨디션에 해당하는
테인트를 자동으로 생성한다.
마찬가지로 스케줄러는 노드 컨디션을 확인하지 않는다. 대신 스케줄러는 테인트를 확인한다. 이렇게 하면 노드 컨디션이 노드에 스케줄된 내용에 영향을 미치지 않는다. 사용자는 적절한 파드 톨러레이션을 추가하여 노드의 일부 문제(노드 컨디션으로 표시)를 무시하도록 선택할 수 있다.
쿠버네티스 1.8 버전부터 데몬셋 컨트롤러는 다음의 NoSchedule 톨러레이션을
모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 방지한다.
kube-scheduler는
쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
노드에 파드를 배치하는 역할을 한다.
파드의 스케줄링 요건을 충족하는
클러스터의 노드를 파드에 적합한(feasible) 노드라고 한다. 스케줄러는
파드에 대해 적합한 노드를 찾고 기능 셋을 실행하여 해당 노드의 점수를
측정한다. 그리고 스케줄러는 파드를 실행하는데 적합한 모든 노드 중 가장
높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 바인딩 이라는 프로세스로
API 서버에 해당 결정을 통지한다.
본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝
최적화에 대해 설명한다.
큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간
(새 파드가 빠르게 배치됨)과 정확도(스케줄러가 배치 결정을 잘 못하는 경우가 드물게 됨)
사이에서의 스케줄링 결과를 균형 잡을 수 있다.
kube-scheduler 의 percentageOfNodesToScore 설정을 통해
이 튜닝을 구성 한다. 이 KubeSchedulerConfiguration 설정에 따라 클러스터의
노드를 스케줄링할 수 있는 임계값이 결정된다.
임계값 설정하기
percentageOfNodesToScore 옵션은 0과 100 사이의 값을
허용한다. 값 0은 kube-scheduler가 컴파일 된 기본값을
사용한다는 것을 나타내는 특별한 숫자이다.
percentageOfNodesToScore 를 100 보다 높게 설정해도 kube-scheduler는
마치 100을 설정한 것처럼 작동한다.
값을 변경하려면,
kube-scheduler 구성 파일을
편집한 다음 스케줄러를 재시작한다.
대부분의 경우, 구성 파일은 /etc/kubernetes/config/kube-scheduler.yaml 에서 찾을 수 있다.
이를 변경한 후에 다음을 실행해서
kubectl get pods -n kube-system | grep kube-scheduler
kube-scheduler 컴포넌트가 정상인지 확인할 수 있다.
노드 스코어링(scoring) 임계값
스케줄링 성능을 향상시키기 위해 kube-scheduler는 실행 가능한
노드가 충분히 발견되면 이를 찾는 것을 중단할 수 있다. 큰 규모의 클러스터에서는
모든 노드를 고려하는 고지식한 접근 방식에 비해 시간이 절약된다.
클러스터에 있는 모든 노드의 정수 백분율로 충분한 노두의 수에
대한 임계값을 지정한다. kube-scheduler는 이 값을 노드의
정수 값(숫자)로 변환 한다. 스케줄링 중에 kube-scheduler가 구성된
비율을 초과 할만큼 충분히 실행 가능한 노드를 식별한 경우, kube-scheduler는
더 실행 가능한 노드를 찾는 검색을 중지하고
스코어링 단계를 진행한다.
percentageOfNodesToScore는 1과 100 사이의 값이어야 하며
기본값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된
최솟값도 있다.
참고:
클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히
모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한
노드의 수가 충분하지 않기 때문이다.
규모가 작은 클러스터에서는 percentageOfNodesToScore 에 낮은 값을 설정하면,
비슷한 이유로 변경 사항이 거의 또는 전혀 영향을 미치지 않게 된다.
클러스터에 수백 개 이하의 노드가 있는 경우 이 구성 옵션을
기본값으로 둔다. 이는 변경사항을 적용하더라도 스케줄러의
성능이 크게 향상되지 않는다.
이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서
적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서
일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데
가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지
않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다.
percentageOfNodesToScore 를 매우 낮게 설정해서 kube-scheduler가
파드 배치 결정을 잘못 내리지 않도록 해야 한다. 스케줄러의 처리량에
대해 애플리케이션이 중요하고 노드 점수가 중요하지 않은 경우가 아니라면
백분율을 10% 미만으로 설정하지 말아야 한다. 즉, 가능한 한
모든 노드에서 파드를 실행하는 것이 좋다.
스케줄러가 노드 탐색을 반복(iterate)하는 방법
이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을
위해 작성되었다.
클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를
가지도록, 스케줄러는 라운드 로빈(round robin) 방식으로 모든 노드에 대해서 탐색을
반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의
시작부터 시작하여 percentageOfNodesToScore에 명시된 충분한 수의 노드를
찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가
이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막
포인트부터 확인을 재개한다.
만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성
확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서
탐색을 반복한다. 예제로, 2개의 영역에 있는 6개의 노드를 생각해보자.
기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 컴퓨팅 리소스로 실행된다.
리소스 쿼터을 사용하면 클러스터 관리자는 네임스페이스별로 리소스 사용과 생성을 제한할 수 있다.
네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다.
리밋레인지 는 다음과 같은 제약 조건을 제공한다.
네임스페이스에서 파드 또는 컨테이너별 최소 및 최대 컴퓨팅 리소스 사용량을 지정한다.
네임스페이스에서 스토리지클래스별 최소 및 최대 스토리지 요청을 지정한다.
네임스페이스에서 리소스에 대한 요청과 제한 사이의 비율을 지정한다.
네임스페이스에서 컴퓨팅 리소스에 대한 기본 요청/제한을 설정하고 런타임에 있는 컨테이너에 자동으로 설정한다.
리밋레인지 활성화
쿠버네티스 1.10 버전부터 리밋레인지 지원이 기본적으로 활성화되었다.
해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우
특정 네임스페이스에 리밋레인지가 지정된다.
여러 사용자나 팀이 정해진 수의 노드로 클러스터를 공유할 때
한 팀이 공정하게 분배된 리소스보다 많은 리소스를 사용할 수 있다는 우려가 있다.
리소스 쿼터는 관리자가 이 문제를 해결하기 위한 도구이다.
ResourceQuota 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는
제약 조건을 제공한다. 유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와
해당 네임스페이스의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을
제한할 수 있다.
리소스 쿼터는 다음과 같이 작동한다.
다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을
적용하기 위한 지원이 계획되어 있다.
관리자는 각 네임스페이스에 대해 하나의 리소스쿼터를 생성한다.
사용자는 네임스페이스에서 리소스(파드, 서비스 등)를 생성하고 쿼터 시스템은
사용량을 추적하여 리소스쿼터에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다.
리소스를 생성하거나 업데이트할 때 쿼터 제약 조건을 위반하면 위반된 제약 조건을 설명하는
메시지와 함께 HTTP 상태 코드 403 FORBIDDEN으로 요청이 실패한다.
cpu, memory와 같은 컴퓨트 리소스에 대해 네임스페이스에서 쿼터가 활성화된 경우
사용자는 해당값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 쿼터 시스템이
파드 생성을 거부할 수 있다. 힌트: 컴퓨트 리소스 요구 사항이 없는 파드를 기본값으로 설정하려면 LimitRanger 어드미션 컨트롤러를 사용하자.
다음 구문을 사용하여 모든 표준 네임스페이스 처리된(namespaced) 리소스 유형에 대한
특정 리소스 전체 수에 대하여 쿼터를 지정할 수 있다.
코어 그룹이 아닌(non-core) 리소스를 위한 count/<resource>.<group>
코어 그룹의 리소스를 위한 count/<resource>
다음은 사용자가 오브젝트 수 쿼터 아래에 배치하려는 리소스 셋의 예이다.
count/persistentvolumeclaims
count/services
count/secrets
count/configmaps
count/replicationcontrollers
count/deployments.apps
count/replicasets.apps
count/statefulsets.apps
count/jobs.batch
count/cronjobs.batch
사용자 정의 리소스를 위해 동일한 구문을 사용할 수 있다.
예를 들어 example.com API 그룹에서 widgets 사용자 정의 리소스에 대한 쿼터를 생성하려면 count/widgets.example.com을 사용한다.
count/* 리소스 쿼터를 사용할 때 서버 스토리지 영역에 있다면 오브젝트는 쿼터에 대해 과금된다.
이러한 유형의 쿼터는 스토리지 리소스 고갈을 방지하는 데 유용하다. 예를 들어,
크기가 큰 서버에서 시크릿 수에 쿼터를 지정할 수 있다. 클러스터에 시크릿이 너무 많으면 실제로 서버와
컨트롤러가 시작되지 않을 수 있다. 잘못 구성된 크론 잡으로부터의 보호를 위해
잡의 쿼터를 설정할 수 있다. 네임스페이스 내에서 너무 많은 잡을 생성하는 크론 잡은 서비스 거부를 유발할 수 있다.
또한 제한된 리소스 셋에 대해서 일반 오브젝트 수(generic object count) 쿼터를 적용하는 것도 가능하다.
다음 유형이 지원된다.
resourcequota/pods-high created
resourcequota/pods-medium created
resourcequota/pods-low created
kubectl describe quota를 사용하여 Used 쿼터가 0인지 확인하자.
kubectl describe quota
Name: pods-high
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 1k
memory 0 200Gi
pods 0 10
Name: pods-low
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 5
memory 0 10Gi
pods 0 10
Name: pods-medium
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 10
memory 0 20Gi
pods 0 10
우선 순위가 "high"인 파드를 생성한다. 다음 YAML을
high-priority-pod.yml 파일에 저장한다.
apiVersion:v1kind:Podmetadata:name:high-priorityspec:containers:- name:high-priorityimage:ubuntucommand:["/bin/sh"]args:["-c","while true; do echo hello; sleep 10;done"]resources:requests:memory:"10Gi"cpu:"500m"limits:memory:"10Gi"cpu:"500m"priorityClassName:high
kubectl create로 적용하자.
kubectl create -f ./high-priority-pod.yml
"high" 우선 순위 쿼터가 적용된 pods-high에 대한 "Used" 통계가 변경되었고
다른 두 쿼터는 변경되지 않았는지 확인한다.
kubectl describe quota
Name: pods-high
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 500m 1k
memory 10Gi 200Gi
pods 1 10
Name: pods-low
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 5
memory 0 10Gi
pods 0 10
Name: pods-medium
Namespace: default
Resource Used Hard
-------- ---- ----
cpu 0 10
memory 0 20Gi
pods 0 10
요청과 제한의 비교
컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다.
쿼터는 값에 대한 쿼터를 지정하도록 구성할 수 있다.
쿼터에 requests.cpu나 requests.memory에 지정된 값이 있으면 들어오는 모든
컨테이너가 해당 리소스에 대한 명시적인 요청을 지정해야 한다. 쿼터에 limits.cpu나
limits.memory에 지정된 값이 있으면 들어오는 모든 컨테이너가 해당 리소스에 대한 명시적인 제한을 지정해야 한다.
파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
부여할 수 있다.
파드 시큐리티 폴리시란?
Pod Security Policy 는 파드 명세의 보안 관련 측면을 제어하는 클러스터-레벨의
리소스이다. 파드시큐리티폴리시 오브젝트는
관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는
조건 셋을 정의한다. 관리자는
다음을 제어할 수 있다.
파드 시큐리티 폴리시 제어는 선택 사항(하지만 권장함)인
어드미션
컨트롤러로
구현된다. 어드미션 컨트롤러 활성화하면
파드시큐리티폴리시가 적용되지만,
정책을 승인하지 않고 활성화하면 클러스터에
파드가 생성되지 않는다.
파드 시큐리티 폴리시 API(policy/v1beta1/podsecuritypolicy)는
어드미션 컨트롤러와 독립적으로 활성화되므로 기존 클러스터의 경우
어드미션 컨트롤러를 활성화하기 전에 정책을 추가하고 권한을
부여하는 것이 좋다.
정책 승인
파드시큐리티폴리시 리소스가 생성되면 아무 것도 수행하지 않는다. 이를 사용하려면
요청 사용자 또는 대상 파드의
서비스 어카운트는
정책에서 use 동사를 허용하여 정책을 사용할 권한이 있어야 한다.
대부분의 쿠버네티스 파드는 사용자가 직접 만들지 않는다. 대신 일반적으로
컨트롤러 관리자를 통해
디플로이먼트,
레플리카셋, 또는 기타
템플릿 컨트롤러의 일부로 간접적으로 생성된다. 컨트롤러에 정책에 대한 접근 권한을 부여하면
해당 컨트롤러에 의해 생성된 모든 파드에 대한 접근 권한이 부여되므로 정책을 승인하는
기본 방법은 파드의 서비스 어카운트에 대한 접근 권한을
부여하는 것이다(예 참고).
RBAC을 통한 방법
RBAC은 표준 쿠버네티스 권한 부여 모드이며,
정책 사용 권한을 부여하는 데 쉽게 사용할 수 있다.
먼저, Role 또는 ClusterRole은 원하는 정책을 use 하려면 접근 권한을 부여해야 한다.
접근 권한을 부여하는 규칙은 다음과 같다.
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:<role name>rules:- apiGroups:['policy']resources:['podsecuritypolicies']verbs:['use']resourceNames:- <list of policies to authorize>
그런 다음 (Cluster)Role이 승인된 사용자에게 바인딩된다.
apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:<binding name>roleRef:kind:ClusterRolename:<role name>apiGroup:rbac.authorization.k8s.iosubjects:# Authorize specific service accounts:- kind:ServiceAccountname:<authorized service account name>namespace:<authorized pod namespace># Authorize specific users (not recommended):- kind:UserapiGroup:rbac.authorization.k8s.ioname:<authorized user name>
RoleBinding(ClusterRoleBinding 아님)을 사용하는 경우, 바인딩과 동일한 네임스페이스에서
실행되는 파드에 대해서만 사용 권한을 부여한다. 네임스페이스에서 실행되는 모든 파드에 접근 권한을
부여하기 위해 시스템 그룹과 쌍을 이룰 수 있다.
# Authorize all service accounts in a namespace:- kind:GroupapiGroup:rbac.authorization.k8s.ioname:system:serviceaccounts# Or equivalently, all authenticated users in a namespace:- kind:GroupapiGroup:rbac.authorization.k8s.ioname:system:authenticated
RBAC 바인딩에 대한 자세한 예는,
역할 바인딩 예제를 참고하길 바란다.
파드시큐리티폴리시 인증에 대한 전체 예제는
아래를 참고하길 바란다.
문제 해결
컨트롤러 관리자는
보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다.
API 서버 접근 제어에 대한 자세한 내용은
쿠버네티스 API에 대한 접근 제어를 참고하길 바란다.
컨트롤러 관리자가 신뢰할 수 있는 API 포트(localhost 리스너라고도 함)를
통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고,
모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를
만들 수 있는 권한을 부여할 수 있다.
apiVersion:policy/v1beta1kind:PodSecurityPolicymetadata:name:examplespec:privileged:false# 특권을 가진 파드는 허용금지!# 나머지는 일부 필수 필드를 채운다.seLinux:rule:RunAsAnysupplementalGroups:rule:RunAsAnyrunAsUser:rule:RunAsAnyfsGroup:rule:RunAsAnyvolumes:- '*'
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
계속 진행하기 전에 파드를 삭제하자.
kubectl-user delete pod pause
다른 파드를 실행
약간 다르게 다시 시도해보자.
kubectl-user create deployment pause --image=k8s.gcr.io/pause
deployment "pause" created
kubectl-user get pods
No resources found.
kubectl-user get events | head -n 2
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request
무슨 일이 일어났나? 우리는 이미 fake-user에 대해 psp:unprivileged 역할을 바인딩했는데,
Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request 오류가
발생하는 이유는 무엇인가? 그 답은 소스인 replicaset-controller에 있다. Fake-user가
디플로이먼트를 성공적으로 생성했지만(레플리카셋을 성공적으로 생성했음), 레플리카셋이
파드를 생성했을 때 podsecuritypolicy 예제를
사용할 권한이 없었다.
이 문제를 해결하려면 psp:unprivileged 역할을 파드의 서비스 어카운트에 대신
바인딩한다. 이 경우(지정하지 않았으므로) 서비스 어카운트는
default이다.
apiVersion:policy/v1beta1kind:PodSecurityPolicymetadata:name:restrictedannotations:seccomp.security.alpha.kubernetes.io/allowedProfileNames:'docker/default,runtime/default'apparmor.security.beta.kubernetes.io/allowedProfileNames:'runtime/default'seccomp.security.alpha.kubernetes.io/defaultProfileName:'runtime/default'apparmor.security.beta.kubernetes.io/defaultProfileName:'runtime/default'spec:privileged:false# 루트로의 에스컬레이션을 방지하는데 필요하다.allowPrivilegeEscalation:false# 이것은 루트가 아닌 사용자 + 권한 에스컬레이션을 허용하지 않는 것으로 중복이지만,# 심층 방어를 위해 이를 제공한다.requiredDropCapabilities:- ALL# 기본 볼륨 유형을 허용한다.volumes:- 'configMap'- 'emptyDir'- 'projected'- 'secret'- 'downwardAPI'# 클러스터 관리자가 설정한 퍼시스턴트볼륨을 사용하는 것이 안전하다고 가정한다.- 'persistentVolumeClaim'hostNetwork:falsehostIPC:falsehostPID:falserunAsUser:# 루트 권한없이 컨테이너를 실행해야 한다.rule:'MustRunAsNonRoot'seLinux:# 이 정책은 노드가 SELinux가 아닌 AppArmor를 사용한다고 가정한다.rule:'RunAsAny'supplementalGroups:rule:'MustRunAs'ranges:# 루트 그룹을 추가하지 않는다.- min:1max:65535fsGroup:rule:'MustRunAs'ranges:# 루트 그룹을 추가하지 않는다.- min:1max:65535readOnlyRootFilesystem:false
Privileged - 파드의 컨테이너가 특권 모드를 사용할 수 있는지 여부를 결정한다.
기본적으로 컨테이너는 호스트의 모든 장치에 접근할 수 없지만
"특권을 가진" 컨테이너는 호스트의 모든 장치에 접근할 수 있다. 이것은
컨테이너가 호스트에서 실행되는 프로세스와 거의 동일한 접근을 허용한다.
이것은 네트워크 스택 조작 및 장치 접근과 같은
리눅스 기능을 사용하려는 컨테이너에 유용하다.
호스트 네임스페이스
HostPID - 파드 컨테이너가 호스트 프로세스 ID 네임스페이스를 공유할 수 있는지 여부를
제어한다. ptrace와 함께 사용하면 컨테이너 외부로 권한을 에스컬레이션하는 데 사용할 수
있다(ptrace는 기본적으로 금지되어 있음).
HostIPC - 파드 컨테이너가 호스트 IPC 네임스페이스를 공유할 수 있는지 여부를
제어한다.
HostNetwork - 파드가 노드 네트워크 네임스페이스를 사용할 수 있는지 여부를 제어한다.
이렇게 하면 파드에 루프백 장치에 접근 권한을 주고, 서비스는 로컬호스트(localhost)를 리스닝할 수 있으며,
동일한 노드에 있는 다른 파드의 네트워크 활동을 스누핑(snoop)하는 데
사용할 수 있다.
HostPorts - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 목록을
제공한다. min과 max를 포함하여 HostPortRange의 목록으로 정의된다.
기본값은 허용하는 호스트 포트 없음(no allowed host ports)이다.
볼륨 및 파일시스템
Volumes - 허용되는 볼륨 유형의 목록을 제공한다. 허용 가능한 값은
볼륨을 생성할 때 정의된 볼륨 소스에 따른다. 볼륨 유형의 전체 목록은
볼륨 유형들에서 참고한다.
또한 *를 사용하여 모든 볼륨 유형을
허용할 수 있다.
새 PSP에 허용되는 볼륨의 최소 권장 셋 은 다음과 같다.
컨피그맵
다운워드API
emptyDir
퍼시스턴트볼륨클레임
시크릿
프로젝티드(projected)
경고: 파드시큐리티폴리시는 PersistentVolumeClaim이 참조할 수 있는 PersistentVolume
오브젝트의 유형을 제한하지 않으며 hostPath 유형
PersistentVolumes은 읽기-전용 접근 모드를 지원하지 않는다. 신뢰할 수 있는 사용자만
PersistentVolume 오브젝트를 생성할 수 있는 권한을 부여 받아야 한다.
FSGroup - 일부 볼륨에 적용되는 보충 그룹(supplemental group)을 제어한다.
MustRunAs - 하나 이상의 range를 지정해야 한다. 첫 번째 범위의 최솟값을
기본값으로 사용한다. 모든 범위에 대해 검증한다.
MayRunAs - 하나 이상의 range를 지정해야 한다. 기본값을 제공하지 않고
FSGroups을 설정하지 않은 상태로 둘 수 있다. FSGroups이 설정된 경우 모든 범위에 대해
유효성을 검사한다.
RunAsAny - 기본값은 제공되지 않는다. 어떠한 fsGroup ID의 지정도 허용한다.
AllowedHostPaths - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 목록을
지정한다. 빈 목록은 사용되는 호스트 경로에 제한이 없음을 의미한다.
이는 단일 pathPrefix 필드가 있는 오브젝트 목록으로 정의되며, hostPath 볼륨은
허용된 접두사로 시작하는 경로를 마운트할 수 있으며 readOnly 필드는
읽기-전용으로 마운트 되어야 함을 나타낸다.
예를 들면 다음과 같습니다.
allowedHostPaths:# 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만,# "/fool", "/etc/foo" 등은 허용하지 않는다.# "/foo/../" 는 절대 유효하지 않다.- pathPrefix:"/foo"readOnly:true# 읽기 전용 마운트만 허용
경고:
호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션
(다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할
수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다.
쓰기 가능한 hostPath 디렉터리 볼륨을 사용하면, 컨테이너가 pathPrefix 외부의
호스트 파일시스템에 대한 통행을 허용하는 방식으로 컨테이너의 파일시스템 쓰기(write)를 허용한다.
쿠버네티스 1.11 이상 버전에서 사용 가능한 readOnly: true는 지정된 pathPrefix에 대한
접근을 효과적으로 제한하기 위해 모든allowedHostPaths에서 사용해야 한다.
ReadOnlyRootFilesystem - 컨테이너는 읽기-전용 루트 파일시스템(즉, 쓰기 가능한 레이어 없음)으로
실행해야 한다.
FlexVolume 드라이버
flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 목록을 지정한다.
빈 목록 또는 nil은 드라이버에 제한이 없음을 의미한다.
volumes 필드에 flexVolume 볼륨 유형이 포함되어
있는지 확인한다. 그렇지 않으면 FlexVolume 드라이버가 허용되지 않는다.
예를 들면 다음과 같다.
apiVersion:policy/v1beta1kind:PodSecurityPolicymetadata:name:allow-flex-volumesspec:# ... 다른 스펙 필드volumes:- flexVolumeallowedFlexVolumes:- driver:example/lvm- driver:example/cifs
사용자 및 그룹
RunAsUser - 컨테이너를 실행할 사용자 ID를 제어힌다.
MustRunAs - 하나 이상의 range를 지정해야 한다. 첫 번째 범위의 최솟값을
기본값으로 사용한다. 모든 범위에 대해 검증한다.
MustRunAsNonRoot - 파드가 0이 아닌 runAsUser로 제출되거나
이미지에 USER 지시문이 정의되어 있어야 한다(숫자 UID 사용). runAsNonRoot 또는
runAsUser 설정을 지정하지 않은 파드는 runAsNonRoot=true를 설정하도록
변경되므로 컨테이너에 0이 아닌 숫자가 정의된 USER 지시문이
필요하다. 기본값은 제공되지 않는다.
이 전략에서는 allowPrivilegeEscalation=false를 설정하는 것이 좋다.
RunAsAny - 기본값은 제공되지 않는다. 어떠한 runAsUser의 지정도 허용한다.
RunAsGroup - 컨테이너가 실행될 기본 그룹 ID를 제어한다.
MustRunAs - 하나 이상의 range를 지정해야 한다. 첫 번째 범위의 최솟값을
기본값으로 사용한다. 모든 범위에 대해 검증한다.
MayRunAs - RunAsGroup을 지정할 필요가 없다. 그러나 RunAsGroup을 지정하면
정의된 범위에 속해야 한다.
RunAsAny - 기본값은 제공되지 않는다. 어떠한 runAsGroup의 지정도 허용한다.
SupplementalGroups - 컨테이너가 추가할 그룹 ID를 제어한다.
MustRunAs - 하나 이상의 range를 지정해야 한다. 첫 번째 범위의 최솟값을
기본값으로 사용한다. 모든 범위에 대해 검증한다.
MayRunAs - 하나 이상의 range를 지정해야 한다. supplementalGroups에
기본값을 제공하지 않고 설정하지 않은 상태로 둘 수 있다.
supplementalGroups가 설정된 경우 모든 범위에 대해 유효성을 검증한다.
RunAsAny - 기본값은 제공되지 않는다. 어떠한 supplementalGroups의 지정도
허용한다.
권한 에스컬레이션
이 옵션은 allowPrivilegeEscalation 컨테이너 옵션을 제어한다. 이 bool은
컨테이너 프로세스에서
no_new_privs
플래그가 설정되는지 여부를 직접 제어한다. 이 플래그는 setuid 바이너리가
유효 사용자 ID를 변경하지 못하게 하고 파일에 추가 기능을 활성화하지 못하게
한다(예: ping 도구 사용을 못하게 함). MustRunAsNonRoot를 효과적으로
강제하려면 이 동작이 필요하다.
AllowPrivilegeEscalation - 사용자가 컨테이너의 보안 컨텍스트를
allowPrivilegeEscalation=true로 설정할 수 있는지 여부를 게이트한다.
이 기본값은 setuid 바이너리를 중단하지 않도록 허용한다. 이를 false로 설정하면
컨테이너의 하위 프로세스가 상위 프로세스보다 더 많은 권한을 얻을 수 없다.
DefaultAllowPrivilegeEscalation - allowPrivilegeEscalation 옵션의
기본값을 설정한다. 이것이 없는 기본 동작은 setuid 바이너리를 중단하지 않도록
권한 에스컬레이션을 허용하는 것이다. 해당 동작이 필요하지 않은 경우 이 필드를 사용하여
기본적으로 허용하지 않도록 설정할 수 있지만 파드는 여전히 allowPrivilegeEscalation을
명시적으로 요청할 수 있다.
기능
리눅스 기능은 전통적으로 슈퍼유저와 관련된 권한을 보다 세밀하게 분류한다.
이러한 기능 중 일부는 권한 에스컬레이션 또는 컨테이너 분류에 사용될 수 있으며
파드시큐리티폴리시에 의해 제한될 수 있다. 리눅스 기능에 대한 자세한 내용은
기능(7)을
참고하길 바란다.
다음 필드는 대문자로 표기된 기능 이름 목록을
CAP_ 접두사 없이 가져온다.
AllowedCapabilities - 컨테이너에 추가될 수 있는 기능의 목록을
제공한다. 기본적인 기능 셋은 암시적으로 허용된다. 비어있는 셋은
기본 셋을 넘어서는 추가 기능이 추가되지 않는 것을
의미한다. *는 모든 기능을 허용하는 데 사용할 수 있다.
RequiredDropCapabilities - 컨테이너에서 삭제해야 하는 기능이다.
이러한 기능은 기본 셋에서 제거되며 추가해서는 안된다.
RequiredDropCapabilities에 나열된 기능은 AllowedCapabilities 또는
DefaultAddCapabilities에 포함되지 않아야 한다.
DefaultAddCapabilities - 런타임 기본값 외에 기본적으로 컨테이너에 추가되는 기능이다.
도커 런타임을 사용할 때 기본 기능 목록은
도커 문서를
참고하길 바란다.
SELinux
MustRunAs - seLinuxOptions을 구성해야 한다.
seLinuxOptions을 기본값으로 사용한다. seLinuxOptions에 대해 유효성을 검사한다.
RunAsAny - 기본값은 제공되지 않는다. 어떠한 seLinuxOptions의 지정도
허용한다.
AllowedProcMountTypes
allowedProcMountTypes는 허용된 ProcMountTypes의 목록이다.
비어 있거나 nil은 DefaultProcMountType만 사용할 수 있음을 나타낸다.
DefaultProcMount는 /proc의 읽기 전용 및 마스킹(masking)된 경로에 컨테이너 런타임
기본값을 사용한다. 대부분의 컨테이너 런타임은 특수 장치나 정보가 실수로 보안에
노출되지 않도록 /proc의 특정 경로를 마스킹한다. 이것은 문자열
Default로 표시된다.
유일하게 다른 ProcMountType은 UnmaskedProcMount로, 컨테이너 런타임의
기본 마스킹 동작을 무시하고 새로 작성된 /proc 컨테이너가 수정없이
그대로 유지되도록 한다. 이 문자열은
Unmasked로 표시된다.
쿠버네티스 v1.19부터 파드나 컨테이너의 securityContext 에서
seccompProfile 필드를 사용하여 seccomp 프로파일 사용을
제어할 수 있다. 이전 버전에서는, 파드에
어노테이션을 추가하여 seccomp를 제어했다. 두 버전에서 동일한 파드시큐리티폴리시를 사용하여
이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다.
seccomp.security.alpha.kubernetes.io/defaultProfileName - 컨테이너에
적용할 기본 seccomp 프로파일을 지정하는 어노테이션이다. 가능한 값은
다음과 같다.
docker/default - 도커 기본 seccomp 프로파일이 사용된다. 쿠버네티스 1.11 부터 사용 중단(deprecated)
되었다. 대신 runtime/default 사용을 권장한다.
localhost/<path> - <seccomp_root>/<path>에 있는 노드에서 파일을 프로파일로
지정한다. 여기서 <seccomp_root>는 Kubelet의 --seccomp-profile-root 플래그를
통해 정의된다. --seccomp-profile-root 플래그가
정의되어 있지 않으면, <root-dir> 이 --root-dir 플래그로
지정된 <root-dir>/seccomp 기본 경로가 사용된다.
참고:--seccomp-profile-root 플래그는 쿠버네티스 v1.19부터 더 이상 사용되지
않는다. 사용자는 기본 경로를 사용하는 것이 좋다.
seccomp.security.alpha.kubernetes.io/allowedProfileNames - 파드 seccomp
어노테이션에 허용되는 값을 지정하는 어노테이션. 쉼표로 구분된
허용된 값의 목록으로 지정된다. 가능한 값은 위에 나열된 값과
모든 프로파일을 허용하는 * 이다.
이 주석이 없으면 기본값을 변경할 수 없다.
Sysctl
기본적으로 모든 안전한 sysctls가 허용된다.
forbiddenSysctls - 특정 sysctls를 제외한다. 목록에서 안전한 것과 안전하지 않은 sysctls의 조합을 금지할 수 있다. 모든 sysctls 설정을 금지하려면 자체적으로 *를 사용한다.
allowedUnsafeSysctls - forbiddenSysctls에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.
동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 함께 배포할 수 있다.
URL을 구성 소스로 지정할 수도 있다. 이는 GitHub에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
리소스가 많을 경우, -l 또는 --selector 를 사용하여 지정된 셀렉터(레이블 쿼리)를 지정하여 레이블별로 리소스를 필터링하는 것이 더 쉽다.
kubectl delete deployment,services -l app=nginx
deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted
kubectl 은 입력을 받아들이는 것과 동일한 구문으로 리소스 이름을 출력하므로, $() 또는 xargs 를 사용하여 작업을 연결할 수 있다.
kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)
kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service | xargs -i kubectl get {}
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx-svc LoadBalancer 10.0.0.208 <pending> 80/TCP 0s
위의 명령을 사용하여, 먼저 examples/application/nginx/ 에 리소스를 생성하고 -o name 출력 형식으로 생성한 리소스를 출력한다(각 리소스를 resource/name으로 출력).
그런 다음 "service"만 grep 한 다음 kubectl get 으로 출력한다.
특정 디렉터리 내의 여러 서브 디렉터리에서 리소스를 구성하는 경우, --filename,-f 플래그와 함께 --recursive 또는 -R 을 지정하여, 서브 디렉터리에 대한 작업을 재귀적으로 수행할 수도 있다.
예를 들어, 리소스 유형별로 구성된 개발 환경에 필요한 모든 매니페스트를 보유하는 project/k8s/development 디렉터리가 있다고 가정하자.
namespace/development created
namespace/staging created
configmap/my-config created
deployment.apps/my-deployment created
persistentvolumeclaim/my-pvc created
NAME READY STATUS RESTARTS AGE
guestbook-redis-slave-2q2yf 1/1 Running 0 3m
guestbook-redis-slave-qgazl 1/1 Running 0 3m
카나리(canary) 디플로이먼트
여러 레이블이 필요한 또 다른 시나리오는 동일한 컴포넌트의 다른 릴리스 또는 구성의 디플로이먼트를 구별하는 것이다. 새 릴리스가 완전히 롤아웃되기 전에 실제 운영 트래픽을 수신할 수 있도록 새로운 애플리케이션 릴리스(파드 템플리트의 이미지 태그를 통해 지정됨)의 카나리 를 이전 릴리스와 나란히 배포하는 것이 일반적이다.
예를 들어, track 레이블을 사용하여 다른 릴리스를 구별할 수 있다.
기본(primary), 안정(stable) 릴리스에는 값이 stable 인 track 레이블이 있다.
먼저 "app=nginx" 레이블이 있는 모든 파드를 필터링한 다음, "tier=fe" 레이블을 지정한다.
레이블을 지정한 파드를 보려면, 다음을 실행한다.
kubectl get pods -l app=nginx -L tier
NAME READY STATUS RESTARTS AGE TIER
my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe
my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe
my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
그러면 파드 티어의 추가 레이블 열(-L 또는 --label-columns 로 지정)과 함께, 모든 "app=nginx" 파드가 출력된다.
참고로 kubectl apply 는 이전의 호출 이후 구성의 변경 사항을 판별하기 위해 리소스에 어노테이션을 첨부한다. 호출되면, kubectl apply 는 리소스를 수정하는 방법을 결정하기 위해, 이전 구성과 제공된 입력 및 리소스의 현재 구성 간에 3-way diff를 수행한다.
현재, 이 어노테이션 없이 리소스가 생성되므로, kubectl apply 의 첫 번째 호출은 제공된 입력과 리소스의 현재 구성 사이의 2-way diff로 대체된다. 이 첫 번째 호출 중에는, 리소스를 생성할 때 설정된 특성의 삭제를 감지할 수 없다. 이러한 이유로, 그 특성들을 삭제하지 않는다.
kubectl apply 에 대한 모든 후속 호출, 그리고 kubectl replace 및 kubectl edit 와 같이 구성을 수정하는 다른 명령은, 어노테이션을 업데이트하여, kubectl apply 에 대한 후속 호출이 3-way diff를 사용하여 삭제를 감지하고 수행할 수 있도록 한다.
kubectl edit
또는, kubectl edit로 리소스를 업데이트할 수도 있다.
kubectl edit deployment/my-nginx
이것은 먼저 리소스를 get 하여, 텍스트 편집기에서 편집한 다음, 업데이트된 버전으로 리소스를 apply 하는 것과 같다.
kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
vi /tmp/nginx.yaml
# 편집한 다음, 파일을 저장한다.
kubectl apply -f /tmp/nginx.yaml
deployment.apps/my-nginx configured
rm /tmp/nginx.yaml
이를 통해 보다 중요한 변경을 더 쉽게 수행할 수 있다. 참고로 EDITOR 또는 KUBE_EDITOR 환경 변수를 사용하여 편집기를 지정할 수 있다.
경우에 따라, 한 번 초기화하면 업데이트할 수 없는 리소스 필드를 업데이트해야 하거나, 디플로이먼트에서 생성된 손상된 파드를 고치는 등의 재귀적 변경을 즉시 원할 수도 있다. 이러한 필드를 변경하려면, replace --force 를 사용하여 리소스를 삭제하고 다시 만든다. 이 경우, 원래 구성 파일을 수정할 수 있다.
1.16.1 버전으로 업데이트하려면, 위에서 배운 kubectl 명령을 사용하여 .spec.template.spec.containers[0].image 를 nginx:1.14.2 에서 nginx:1.16.1 로 변경한다.
kubectl edit deployment/my-nginx
이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며, 원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면, 디플로이먼트 페이지를 방문한다.
쿠버네티스는 애플리케이션 간에 머신을 공유하는 것이다. 일반적으로,
머신을 공유하려면 두 애플리케이션이 동일한 포트를 사용하지 않도록
해야 한다. 여러 개발자 간에 포트를 조정하는 것은 대규모로 실시하기가 매우 어렵고,
사용자가 통제할 수 없는 클러스터 수준의 문제에 노출된다.
동적 포트 할당은 시스템에 많은 복잡성을 야기한다. 모든
애플리케이션은 포트를 플래그로 가져와야 하며, API 서버는 동적 포트 번호를
구성 블록에 삽입하는 방법을 알아야 하고, 서비스는 서로를
찾는 방법 등을 알아야 한다. 쿠버네티스는 이런 것들을 다루는 대신
다른 접근법을 취한다.
쿠버네티스 네트워크 모델
모든 Pod 에는 고유의 IP 주소가 있다. 즉, Pod 간에 링크를 명시적으로
생성할 필요가 없으며 컨테이너 포트를 호스트 포트에 매핑할
필요가 거의 없다. 이렇게 하면 포트 할당, 이름 지정, 서비스 검색, 로드 밸런싱,
애플리케이션 구성 및 마이그레이션 관점에서 Pod 를 VM 또는
물리적 호스트처럼 취급할 수 있는 깔끔하고, 하위 호환성
있는 모델이 생성된다.
쿠버네티스는 모든 네트워크 구현에 다음과 같은
기본 요구 사항을 적용한다(의도적 네트워크 세분화 정책 제외).
노드의 파드는 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다.
노드의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든
파드와 통신할 수 있다.
참고: 호스트 네트워크에서 실행되는 Pod 를 지원하는 리눅스와 같은 플랫폼의 경우, 다음의 요구 사항을
적용한다.
노드의 호스트 네트워크에 있는 파드는 NAT 없이 모든 노드에 있는 모든
파드와 통신할 수 있다.
이 모델은 전체적으로 덜 복잡할 뿐만 아니라, 쿠버네티스를 위해 VM에서
컨테이너로 애플리케이션을 포팅할 때 충돌이 적게 구현하려는 요구와
주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고
프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다.
쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 Pod 범위에 존재한다(Pod 내
컨테이너는 네트워크 네임스페이스를 공유함). 이것은 Pod 내 컨테이너가 모두
localhost 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한
Pod 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도
VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고
한다.
이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다.
Pod 로 전달하는 Node 자체의 포트(호스트 포트라고 함)를
요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은
컨테이너 런타임의 세부 사항이기도 하다. Pod 자체는
호스트 포트의 존재 여부에 대해 인식하지 못한다.
쿠버네티스 네트워크 모델의 구현 방법
이 네트워크 모델을 구현할 수 있는 방법에는 여러 가지가 있다. 이
문서는 다양한 방법에 대한 철저한 연구는 아니지만, 다양한 기술에 대한
소개로 활용되며 도약하는 포인트로 사용되기를 바란다.
이 목록은 알파벳 순으로 정렬되어 있으며, 정렬된 순서가
우선 상태를 의미하는 것은 아니다.
주의:
이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.
프로젝트 Antrea는 쿠버네티스 고유의 오픈소스 쿠버네티스 네트워킹 솔루션이다. 네트워킹 데이터 플레인으로 Open vSwitch를 활용한다. Open vSwitch는 리눅스와 윈도우를 모두 지원하는 고성능의 프로그래밍이 가능한 가상 스위치이다. Antrea는 Open vSwitch를 통해 쿠버네티스 네트워크 정책을 고성능의 효율적인 방식으로 구현할 수 있다.
Antrea는 Open vSwitch의 "프로그래밍이 가능한" 특성으로 인해 Open vSwitch 위에 광범위한 네트워킹 및 보안 기능과 서비스를 구현할 수 있다.
Apstra의 AOS
AOS는 단순한 통합 플랫폼에서 복잡한 데이터센터 환경을 만들고 관리하는 의도기반(Intent-Based) 네트워킹 시스템이다. AOS는 확장성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다.
AOS 레퍼런스 디자인은 현재 레거시 Layer-2 스위칭 문제를 제거하는 Layer-3 연결 호스트를 지원한다. 이 Layer-3 호스트는 리눅스 서버(Debian, Ubuntu, CentOS)일 수 있으며 랙 상단 스위치(TOR)와 직접 BGP 인접 관계를 만든다. AOS는 라우팅 인접성을 자동화한 다음 쿠버네티스 디플로이먼트에서 일반적으로 사용되는 RHI(Route Health Injection)에 대한 세밀한 제어를 제공한다.
AOS는 쿠버네티스가 애플리케이션 요구 사항에 따라 네트워크 정책을 신속하게 변경할 수 있는 풍부한 REST API 엔드포인트 셋을 제공한다. 네트워크 설계에 사용된 AOS 그래프 모델을 워크로드 프로비저닝과 통합하여 프라이빗 클라우드와 퍼블릭 클라우드 모두에 대한 엔드-투-엔드 관리 시스템을 향상시킬 수 있다.
AOS는 Cisco, Arista, Dell, Mellanox, HPE 그리고 Microsoft SONiC, Dell OPX 및 Cumulus Linux와 같은 개방형 네트워크 운영체제와 수많은 화이트-박스 시스템을 포함한 제조업체의 일반적인 벤더 장비 사용을 지원한다.
AWS VPC CNI는 쿠버네티스 클러스터를 위한 통합된 AWS 버추얼 프라이빗 클라우드(Virtual Private Cloud, VPC) 네트워킹을 제공한다. 이 CNI 플러그인은 높은 처리량과 가용성, 낮은 레이턴시(latency) 그리고 최소 네트워크 지터(jitter)를 제공한다. 또한, 사용자는 쿠버네티스 클러스터를 구축하기 위한 기존의 AWS VPC 네트워킹 및 보안 모범 사례를 적용할 수 있다. 여기에는 VPC 플로우 로그, VPC 라우팅 정책과 네트워크 트래픽 격리를 위한 보안 그룹을 사용하는 기능이 포함되어 있다.
이 CNI 플러그인을 사용하면 쿠버네티스 파드는 VPC 네트워크와 동일한 IP 주소를 파드 내부에 가질 수 있다. CNI는 각 쿠버네티스 노드에 AWS 엘라스틱 네트워킹 인터페이스(Elastic Networking Interfaces, ENI)를 할당하고 노드의 파드에 대해 각 ENI의 보조 IP 범위를 사용한다. CNI에는 파드를 빠르게 시작하기 위해 ENI와 IP 주소의 사전 할당 제어 기능이 포함되어 있으며 최대 2,000개의 노드로 구성된 대규모 클러스터가 가능하다.
Azure CNI는 VM과 동등한 네트워크 성능을 제공하는 Azure 버추얼 네트워크(VNet이라고도 알려진)와 쿠버네티스 파드를 통합하는 오픈소스 플러그인이다. 파드는 피어링된 VNet과 Express Route 또는 사이트 간 VPN을 통해 온-프레미스에 연결할 수 있으며 이러한 네트워크에서 직접 연결할 수도 있다. 파드는 서비스 엔드포인트 또는 프라이빗 링크로 보호되는 스토리지와 SQL과 같은 Azure 서비스에 접근할 수 있다. VNet 보안 정책과 라우팅을 사용하여 파드 트래픽을 필터링할 수 있다. 플러그인은 쿠버네티스 노드의 네트워크 인터페이스에 사전 구성된 보조 IP 풀을 활용하여 VNet IP를 파드에 할당한다.
빅 클라우드 패브릭은 클라우드 네이티브 네트워킹 아키텍처로, 프라이빗 클라우드/온-프레미스 환경에서 쿠버네티스를 실행하도록 디자인되었다. 통합된 물리 및 가상 SDN을 사용하여, 빅 클라우드 패브릭은 로드 밸런싱, 가시성, 문제 해결, 보안 정책 및 컨테이너 트래픽 모니터링과 같은 내재한 컨테이너 네트워킹 문제를 해결한다.
빅 클라우드 패브릭의 가상 파드 멀티 테넌트 아키텍처를 통해 쿠버네티스, RedHat OpenShift, Mesosphere DC/OS 및 Docker Swarm과 같은 컨테이너 오케스트레이션 시스템은 VMware, OpenStack 및 Nutanix와 같은 VM 오케스트레이션 시스템과 함께 네이티브로 통합된다. 고객은 원하는 수의 클러스터를 안전하게 상호 연결할 수 있으며 필요한 경우 이들 사이의 테넌트 간 통신을 활성화할 수 있다.
가트너는 최신의 매직 쿼드런트(Magic Quadrant)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 여기에서 사례로 참조된다.
캘리코
캘리코는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, 클라우드 제공자 CNI와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다.
실리움(Cilium)
실리움은 애플리케이션 컨테이너 간에
네트워크 연결을 제공하고 투명하게 보호하기 위한 오픈소스 소프트웨어이다.
실리움은 L7/HTTP를 인식하며 네트워크 주소 지정에서 분리된 ID 기반 보안 모델을 사용하여 L3-L7에서
네트워크 정책을 적용할 수 있으며,
다른 CNI 플러그인과 함께 사용할 수 있다.
cni-ipvlan-vpc-k8s는
L2 모드에서 리눅스 커널의 IPvlan 드라이버를 사용하여 Amazon 엘라스틱 네트워크 인터페이스(ENI)를
사용하고 AWS 매니지드 IP를 파드에 바인딩하는
Amazon 버추얼 프라이빗 클라우드(VPC) 환경 내에서 쿠버네티스를 위한
간단하고, 호스트 로컬, 낮은 레이턴시, 높은 처리량 및 호환 네트워킹 스택을 제공하는
CNI와 IPAM 플러그인 셋을 포함한다.
플러그인은 VPC 내에서 구성하고 배포할 수 있도록 간단하게 설계되었다.
Kubelets는 오버레이 네트워크 관리, BGP 관리, 소스/대상 확인 비활성화 또는
VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브넷을
제공(VPC별 50-100개 항목으로 제한)하는 등의 자주 권장되는 복잡성을 요구하지 않고
부팅한 다음 필요에 따라 IP 사용량을 자체 구성하고 확장할
수 있다. 즉, cni-ipvlan-vpc-k8s는 AWS 내에서 쿠버네티스를
대규모로 배포하는 데 필요한 네트워크 복잡성을 크게 줄인다.
Coil
Coil은 통합이 용이하도록 설계된 CNI 플러그인으로 유연한 이그레스(egress) 네트워킹을 제공한다.
Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네트워크에 대해 임의의 이그레스 NAT 게이트웨이를 정의할 수 있다.
콘티브(Contiv)
콘티브는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. 콘티브는 모두 오픈소스이다.
콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric)
텅스텐 패브릭을 기반으로 하는 콘트레일은 진정한 개방형 멀티 클라우드 네트워크 가상화 및 정책 관리 플랫폼이다. 콘트레일 및 텅스텐 패브릭은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 다양한 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어메탈 워크로드에 대해 서로 다른 격리 모드를 제공한다.
DANM
DANM은 쿠버네티스 클러스터에서 실행되는 통신사 워크로드를 위한 네트워킹 솔루션이다. 다음의 컴포넌트로 구성된다.
고급 기능들로 IPVLAN 인터페이스를 프로비저닝할 수 있는 CNI 플러그인
여러 클러스터 전체의 불연속 L3 네트워크를 관리하고 요청 시 동적, 정적 또는 IP를 할당하지 않는 방식을 제공하는 내장 IPAM 모듈
자체 CNI를 통해서, 또는 SRI-OV나 플라넬과 같은 널리 사용되는 CNI 솔루션에 잡을 동시에 위임하여 여러 네트워크 인터페이스를 컨테이너에 연결할 수 있는 CNI 메타플러그인
모든 쿠버네티스 호스트의 VxLAN 및 VLAN 인터페이스를 중앙에서 관리할 수 있는 쿠버네티스 컨트롤러
쿠버네티스의 서비스 기반의 서비스 검색 개념을 확장하여 파드의 모든 네트워크 인터페이스에서 작동하는 다른 쿠버네티스 컨트롤러
이 도구 셋을 통해 DANM은 여러 개의 분리된 네트워크 인터페이스를 제공할 수 있으며, 파드에 다른 네트워킹 백엔드 및 고급 IPAM 기능을 사용할 수 있다.
플라넬
플라넬은 쿠버네티스 요구 사항을
충족하는 매우 간단한 오버레이 네트워크이다. 많은
경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다.
Google 컴퓨트 엔진(GCE)
Google 컴퓨트 엔진 클러스터 구성 스크립트의 경우, 고급
라우팅을 사용하여
각 VM에 서브넷을 할당한다(기본값은 /24 - 254개 IP). 해당 서브넷에 바인딩된
모든 트래픽은 GCE 네트워크 패브릭에 의해 VM으로 직접 라우팅된다. 이는
아웃 바운드 인터넷 접근을 위해 NAT로 구성된 VM에 할당된 "기본"
IP 주소에 추가된다. 리눅스 브릿지(cbr0)는 해당 서브넷에 존재하도록
구성되며, 도커의 --bridge 플래그로 전달된다.
이 브릿지는 노드의 .spec.podCIDR에 따라 Kubelet(--network-plugin=kubenet
플래그로 제어되는)에 의해 생성된다.
도커는 이제 cbr-cidr 블록에서 IP를 할당한다. 컨테이너는 cbr0 브릿지를
통해 서로 Node 에 도달할 수 있다. 이러한 IP는 모두 GCE 프로젝트 네트워크
내에서 라우팅할 수 있다.
그러나, GCE 자체는 이러한 IP에 대해 전혀 알지 못하므로, 아웃 바운드 인터넷 트래픽을 위해
IP를 NAT하지 않는다. 그것을 달성하기 위해 iptables 규칙을 사용하여
GCE 프로젝트 네트워크(10.0.0.0/8) 외부의 IP에 바인딩된 트래픽을
마스커레이드(일명 SNAT - 마치 패킷이 Node 자체에서 온 것처럼
보이게 함)한다.
마지막으로 커널에서 IP 포워딩이 활성화되어 있으므로, 커널은 브릿지된 컨테이너에
대한 패킷을 처리한다.
sysctl net.ipv4.ip_forward=1
이 모든 것의 결과는 모든 Pod 가 서로에게 도달할 수 있고 인터넷으로 트래픽을
송신할 수 있다는 것이다.
재규어(Jaguar)
재규어는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다.
k-vswitch
k-vswitch는 Open vSwitch 기반의 간단한 쿠버네티스 네트워킹 플러그인이다. Open vSwitch의 기존 기능을 활용하여 운영하기 쉽고, 성능이 뛰어나고 안전한 강력한 네트워킹 플러그인을 제공한다.
Knitter
Knitter는 쿠버네티스에서 여러 네트워킹을 지원하는 네트워크 솔루션이다. 테넌트 관리 및 네트워크 관리 기능을 제공한다. Knitter에는 애플리케이션의 IP 주소 유지, IP 주소 마이그레이션 등과 같은 여러 네트워크 플레인 외에 엔드-투-엔드 NFV 컨테이너 네트워킹 솔루션 셋이 포함되어 있다.
Kube-OVN
Kube-OVN은 기업을 위한 OVN 기반 쿠버네티스 네트워크 패브릭이다. OVN/OVS의 도움으로, 서브넷, QoS, 고정 IP 할당, 트래픽 미러링, 게이트웨이, 오픈플로우 기반 네트워크 정책 및 서비스 프록시와 같은 고급 오버레이 네트워크 기능을 제공한다.
Kube-router
kube-router는 쿠버네티스를 위한 특수 목적의 네트워킹 솔루션으로 고성능 및 운영 단순성을 제공한다. 큐브 라우터는 리눅스 LVS/IPVS 기반 서비스 프록시, 오버레이가 없는 리눅스 커널 포워딩 기반의 파드 간 네트워킹 솔루션 그리고 iptables/ipset 기반 네트워크 정책 집행도구를 제공한다.
L2 네트워크 및 리눅스 브릿지
"베어메탈" 환경의 간단한 스위치와 같은 "더미(dumb)" L2 네트워크가 있는 경우,
위의 GCE 설정과 비슷한 작업을 수행할 수 있어야 한다.
이 방법은 매우 우연히 시도되었고 작동하는 것으로 보이지만
철저히 테스트되지 않았다. 이 기술을 사용하여
프로세스를 완료한 경우, 알려주길 바란다.
Lars Kellogg-Stedman이 제공하는
이 훌륭한 튜토리얼의
"With Linux Bridge devices" 섹션을 참고한다.
Multus(멀티 네트워크 플러그인)
Multus는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다.
OVN4NFV-K8S-Plugin은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
NSX-T
VMware NSX-T는 네트워크 가상화 및 보안 플랫폼이다. NSX-T는 멀티 클라우드 및 멀티 하이퍼바이저 환경에 네트워크 가상화를 제공할 수 있으며 이기종 엔드포인트와 기술 스택이 있는 새로운 애플리케이션 프레임워크 및 아키텍처에 중점을 둔다. vSphere 하이퍼바이저 외에도, 이러한 환경에는 KVM, 컨테이너 및 베어메탈과 같은 다른 하이퍼바이저가 포함된다.
NSX-T 컨테이너 플러그인(NCP)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
Nuage Networks VCS(가상 클라우드 서비스)
Nuage는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다.
Nuage 플랫폼은 오버레이를 사용하여 쿠버네티스 파드와 쿠버네티스가 아닌 환경(VM 및 베어메탈 서버) 간에 완벽한 정책 기반의 네트워킹을 제공한다. Nuage의 정책 추상화 모델은 애플리케이션을 염두에 두고 설계되었으며 애플리케이션에 대한 세분화된 정책을 쉽게 선언할 수 있도록 한다. 플랫폼의 실시간 분석 엔진을 통해 쿠버네티스 애플리케이션에 대한 가시성과 보안 모니터링이 가능하다.
OpenVSwitch
OpenVSwitch는 다소 성숙하지만
오버레이 네트워크를 구축하는 복잡한 방법이다. 이것은 네트워킹 분야의 몇몇
"대형 벤더"에 의해 승인되었다.
OVN(오픈 버추얼 네트워킹)
OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
가상화 솔루션이다. 논리적 스위치, 논리적 라우터, 스테이트풀 ACL, 로드 밸런서 등을 생성하여
서로 다른 가상 네트워킹 토폴로지를 구축할 수 있다. 이 프로젝트에는
ovn-kubernetes에
특정 쿠버네티스 플러그인 및 문서가 있다.
로마나
로마나는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 네트워크 폴리시를 지원하여 네트워크 네임스페이스에서 격리를 제공한다.
Weaveworks의 위브넷
위브넷은
쿠버네티스 및 호스팅된 애플리케이션을 위한 탄력적이고 사용하기 쉬운 네트워크이다.
위브넷은 CNI 플러그인 또는
독립형으로 실행된다. 두 버전에서, 실행하기 위해 구성이나 추가 코드가 필요하지 않으며,
두 경우 모두, 쿠버네티스의 표준과 같이 네트워크에서 파드별로 하나의 IP 주소를 제공한다.
다음 내용
네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은
네트워킹 디자인 문서에
자세히 설명되어 있다.
3.11.4 - 로깅 아키텍처
애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다.
예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 애플리케이션의 로그에 접근하고 싶을 것이다.
클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 클러스터-레벨-로깅 이라고 한다.
클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는
로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만,
쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다.
쿠버네티스의 기본 로깅
이 예시는 텍스트를 초당 한 번씩 표준 출력에 쓰는
컨테이너에 대한 Pod 명세를 사용한다.
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
...
kubectl logs --previous 를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다. 파드에 여러 컨테이너가 있는 경우, 명령에 컨테이너 이름을 추가하여 접근하려는 컨테이너 로그를 지정해야 한다. 자세한 내용은 kubectl logs 문서를 참조한다.
노드 레벨에서의 로깅
컨테이너화된 애플리케이션의 stdout(표준 출력) 및 stderr(표준 에러) 스트림에 의해 생성된 모든 출력은 컨테이너 엔진이 처리 및 리디렉션 한다.
예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 로깅 드라이버로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 JSON 형식의 파일에 작성하도록 구성된다.
참고: 도커 JSON 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다.
기본적으로, 컨테이너가 다시 시작되면, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. 파드가 노드에서 축출되면, 해당하는 모든 컨테이너도 로그와 함께 축출된다.
노드-레벨 로깅에서 중요한 고려 사항은 로그 로테이션을 구현하여,
로그가 노드에서 사용 가능한 모든 스토리지를 사용하지 않도록 하는 것이다. 쿠버네티스는
로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로
이를 해결하기 위한 솔루션을 설정해야 한다.
예를 들어, kube-up.sh 스크립트에 의해 배포된 쿠버네티스 클러스터에는,
매시간 실행되도록 구성된 logrotate
도구가 있다. 애플리케이션의 로그를 자동으로
로테이션하도록 컨테이너 런타임을 설정할 수도 있다.
기본 로깅 예제에서와 같이 kubectl logs를
실행하면, 노드의 kubelet이 요청을 처리하고
로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다.
참고: 만약, 일부 외부 시스템이 로테이션을 수행한 경우,
kubectl logs 를 통해 최신 로그 파일의 내용만
사용할 수 있다. 예를 들어, 10MB 파일이 있으면, logrotate 가
로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일)
kubectl logs 는 이 예시에서는 빈 응답에 해당하는 최신 로그 파일을 반환한다.
시스템 컴포넌트 로그
시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
예를 들면 다음과 같다.
쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다.
Kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다.
systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 journald에 작성한다.
systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 /var/log 디렉터리의
.log 파일에 작성한다. 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고,
항상 /var/log 디렉터리에 기록한다.
시스템 컴포넌트는 klog
로깅 라이브러리를 사용한다. 로깅에 대한 개발 문서에서
해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다.
컨테이너 로그와 마찬가지로, /var/log 디렉터리의 시스템 컴포넌트 로그를
로테이트해야 한다. kube-up.sh 스크립트로 구축한 쿠버네티스 클러스터에서
로그는 매일 또는 크기가 100MB를 초과하면
logrotate 도구에 의해 로테이트가 되도록 구성된다.
클러스터 레벨 로깅 아키텍처
쿠버네티스는 클러스터-레벨 로깅을 위한 네이티브 솔루션을 제공하지 않지만, 고려해야 할 몇 가지 일반적인 접근 방법을 고려할 수 있다. 여기 몇 가지 옵션이 있다.
모든 노드에서 실행되는 노드-레벨 로깅 에이전트를 사용한다.
애플리케이션 파드에 로깅을 위한 전용 사이드카 컨테이너를 포함한다.
애플리케이션 내에서 로그를 백엔드로 직접 푸시한다.
노드 로깅 에이전트 사용
각 노드에 노드-레벨 로깅 에이전트 를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다. 로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구이다. 일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너이다.
로깅 에이전트는 모든 노드에서 실행해야 하므로, 에이전트는
DaemonSet 으로 동작시키는 것을 추천한다.
노드-레벨 로깅은 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션에 대한 변경은 필요로 하지 않는다.
컨테이너는 stdout과 stderr를 동의되지 않은 포맷으로 작성한다. 노드-레벨 에이전트는 이러한 로그를 수집하고 취합을 위해 전달한다.
로깅 에이전트와 함께 사이드카 컨테이너 사용
다음 중 한 가지 방법으로 사이드카 컨테이너를 사용할 수 있다.
사이드카 컨테이너는 애플리케이션 로그를 자체 stdout 으로 스트리밍한다.
사이드카 컨테이너는 로깅 에이전트를 실행하며, 애플리케이션 컨테이너에서 로그를 가져오도록 구성된다.
사이드카 컨테이너 스트리밍
사이드카 컨테이너가 자체 stdout 및 stderr 스트림으로
쓰도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를
활용할 수 있다. 사이드카 컨테이너는 파일, 소켓 또는 journald에서 로그를 읽는다.
각 사이드카 컨테이너는 자체 stdout 또는 stderr 스트림에 로그를 출력한다.
이 방법을 사용하면 애플리케이션의 다른 부분에서 여러 로그 스트림을
분리할 수 있고, 이 중 일부는 stdout 또는 stderr 에
작성하기 위한 지원이 부족할 수 있다. 로그를 리디렉션하는 로직은
최소화되어 있기 때문에, 심각한 오버헤드가 아니다. 또한,
stdout 및 stderr 가 kubelet에서 처리되므로, kubectl logs 와 같은
빌트인 도구를 사용할 수 있다.
예를 들어, 파드는 단일 컨테이너를 실행하고, 컨테이너는
서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한
구성 파일은 다음과 같다.
apiVersion:v1kind:Podmetadata:name:counterspec:containers:- name:countimage:busyboxargs:- /bin/sh- -c- > i=0;
while true;
do
echo "$i: $(date)" >> /var/log/1.log;
echo "$(date) INFO $i" >> /var/log/2.log;
i=$((i+1));
sleep 1;
donevolumeMounts:- name:varlogmountPath:/var/logvolumes:- name:varlogemptyDir:{}
두 컴포넌트를 컨테이너의 stdout 스트림으로 리디렉션한 경우에도, 동일한 로그
스트림에 서로 다른 형식의 로그 항목을 작성하는 것은
추천하지 않는다. 대신, 두 개의 사이드카 컨테이너를 생성할 수 있다. 각 사이드카
컨테이너는 공유 볼륨에서 특정 로그 파일을 테일(tail)한 다음 로그를
자체 stdout 스트림으로 리디렉션할 수 있다.
이제 이 파드를 실행하면, 다음의 명령을 실행하여 각 로그 스트림에
개별적으로 접근할 수 있다.
kubectl logs counter count-log-1
출력은 다음과 같다.
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
...
kubectl logs counter count-log-2
출력은 다음과 같다.
Mon Jan 1 00:00:00 UTC 2001 INFO 0
Mon Jan 1 00:00:01 UTC 2001 INFO 1
Mon Jan 1 00:00:02 UTC 2001 INFO 2
...
클러스터에 설치된 노드-레벨 에이전트는 추가 구성없이
자동으로 해당 로그 스트림을 선택한다. 원한다면, 소스 컨테이너에
따라 로그 라인을 파싱(parse)하도록 에이전트를 구성할 수 있다.
참고로, CPU 및 메모리 사용량이 낮음에도 불구하고(cpu에 대한 몇 밀리코어의
요구와 메모리에 대한 몇 메가바이트의 요구), 로그를 파일에 기록한 다음
stdout 으로 스트리밍하면 디스크 사용량은 두 배가 될 수 있다. 단일 파일에
쓰는 애플리케이션이 있는 경우, 일반적으로 스트리밍
사이드카 컨테이너 방식을 구현하는 대신 /dev/stdout 을 대상으로
설정하는 것을 추천한다.
사이드카 컨테이너를 사용하여 애플리케이션 자체에서 로테이션할 수 없는
로그 파일을 로테이션할 수도 있다. 이 방법의 예시는 정기적으로 logrotate 를 실행하는 작은 컨테이너를 두는 것이다.
그러나, stdout 및 stderr 을 직접 사용하고 로테이션과
유지 정책을 kubelet에 두는 것이 권장된다.
로깅 에이전트가 있는 사이드카 컨테이너
노드-레벨 로깅 에이전트가 상황에 맞게 충분히 유연하지 않은 경우,
애플리케이션과 함께 실행하도록 특별히 구성된 별도의 로깅 에이전트를 사용하여
사이드카 컨테이너를 생성할 수 있다.
참고: 사이드카 컨테이너에서 로깅 에이전트를 사용하면
상당한 리소스 소비로 이어질 수 있다. 게다가, kubelet에 의해
제어되지 않기 때문에, kubectl logs 를 사용하여 해당 로그에
접근할 수 없다.
여기에 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 구성 파일이 있다. 첫 번째 파일에는
fluentd를 구성하기 위한 ConfigMap이 포함되어 있다.
apiVersion:v1kind:ConfigMapmetadata:name:fluentd-configdata:fluentd.conf:| <source>
type tail
format none
path /var/log/1.log
pos_file /var/log/1.log.pos
tag count.format1
</source>
<source>
type tail
format none
path /var/log/2.log
pos_file /var/log/2.log.pos
tag count.format2
</source>
<match **>
type google_cloud
</match>
참고: fluentd를 구성하는 것에 대한 자세한 내용은, fluentd 문서를 참고한다.
두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다.
파드는 fluentd가 구성 데이터를 가져올 수 있는 볼륨을 마운트한다.
사용 중단된 메트릭은 해당 메트릭이 결국 삭제된다는 것을 나타내지만, 아직은 사용 가능하다는 뜻이다.
이 메트릭은 어느 버전에서부터 사용 중단된 것인지를 표시하는 어노테이션을 포함한다.
예를 들면,
사용 중단 이전에는 다음과 같다.
# HELP some_counter this counts things
# TYPE some_counter counter
some_counter 0
사용 중단 이후에는 다음과 같다.
# HELP some_counter (Deprecated since 1.15.0) this counts things
# TYPE some_counter counter
some_counter 0
히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, 히든 메트릭 표시 섹션을 참고한다.
삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다.
히든 메트릭 표시
위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다. 관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우 관리자를 위한 임시방편으로 사용된다.
show-hidden-metrics-for-version 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는 버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고, y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다. 그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다.
플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을 show-hidden-metrics-for-version 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다. 사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다.
1.n 버전에서 사용 중단되었다고 가정한 메트릭 A 를 예로 들어보겠다. 메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다.
1.n 릴리스에서는 메트릭이 사용 중단되었으며, 기본적으로 생성될 수 있다.
1.n+1 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며, show-hidden-metrics-for-version=1.n 커맨드 라인에 의해서 생성될 수 있다.
1.n+2 릴리스에서는 코드베이스에서 메트릭이 제거되어야 한다. 더이상 임시방편은 존재하지 않는다.
릴리스 1.12 에서 1.13 으로 업그레이드 중이지만, 1.12 에서 사용 중단된 메트릭 A 를 사용하고 있다면, 커맨드 라인에서 --show-hidden-metrics=1.12 플래그로 히든 메트릭을 설정해야 하고, 1.14 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다.
액셀러레이터 메트릭 비활성화
kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVIDIA GPU와 같은 액셀러레이터의 경우, 이러한 메트릭을 수집하기 위해 kubelet은 드라이버에 열린 핸들을 가진다. 이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해 클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다.
액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. 공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 컨테이너를 제공해야 한다.
[DisableAcceleratorUsageMetrics 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text= DisableAcceleratorUsageMetrics,-false)는 이 기능을 기본적으로 사용하도록 설정하는 타임라인를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다.
컴포넌트 메트릭
kube-controller-manager 메트릭
컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 인사이트를 제공한다.
이러한 메트릭에는 go_routine 수와 같은 일반적인 Go 언어 런타임 메트릭과
etcd 요청 대기 시간 또는 Cloudprovider(AWS, GCE, OpenStack) API 대기 시간과 같은 컨트롤러 특정 메트릭이 포함되어
클러스터의 상태를 측정하는 데 사용할 수 있다.
쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한 상세한 Cloudprovider 메트릭을 사용할 수 있다.
이 메트릭은 퍼시스턴트 볼륨 동작의 상태를 모니터링하는 데 사용할 수 있다.
스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.
kube-scheduler는 각 파드에 대해 구성된 리소스 요청과 제한을 식별한다. 요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. 시계열에는 다음과 같은 레이블이 지정된다.
네임스페이스
파드 이름
파드가 스케줄된 노드 또는 아직 스케줄되지 않은 경우 빈 문자열
우선순위
해당 파드에 할당된 스케줄러
리소스 이름 (예: cpu)
알려진 경우 리소스 단위 (예: cores)
파드가 완료되면 (Never 또는 OnFailure의 restartPolicy가 있고 Succeeded 또는 Failed 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) 스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. 두 메트릭을 kube_pod_resource_request 및 kube_pod_resource_limit 라고 한다.
메트릭은 HTTP 엔드포인트 /metrics/resources에 노출되며 스케줄러의 /metrics 엔드포인트
와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 --show-hidden-metrics-for-version=1.20 플래그를 사용해야 한다.
가비지 수집은 사용되지 않는 이미지들과 컨테이너들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다.
이미지 수집
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
라이프사이클을 관리한다.
이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다.
HighThresholdPercent 와 LowThresholdPercent. 임계값을 초과하는
디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한
이미지들을 삭제한다.
컨테이너 수집
컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다: MinAge 는 컨테이너를 가비지 수집 할 수 있는 최소 연령이다. MaxPerPodContainer 는 모든 단일 파드 (UID, 컨테이너 이름) 쌍이 가질 수 있는
최대 비활성 컨테이너의 수량이다. MaxContainers 죽은 컨테이너의 최대 수량이다. 이러한 변수는 MinAge 를 0으로 설정하고, MaxPerPodContainer 와 MaxContainers 를 각각 0 보다 작게 설정해서 비활성화 할 수 있다.
Kubelet은 미확인, 삭제 또는 앞에서 언급 한 플래그가 설정 한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다. 일반적으로 가장 오래된 컨테이너가 먼저 제거된다. MaxPerPodContainer 와 MaxContainer 는 파드 당 최대 컨테이너 수 (MaxPerPodContainer)가 허용 가능한 범위의 전체 죽은 컨테이너의 수(MaxContainers)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있습니다. 이러한 상황에서 MaxPerPodContainer 가 조정된다: 최악의 시나리오는 MaxPerPodContainer 를 1로 다운그레이드하고 가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유 한 컨테이너는 MinAge 보다 오래된 컨테이너가 제거된다.
kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대상이 아니다.
사용자 설정
여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
image-gc-high-threshold, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
기본값은 85% 이다.
image-gc-low-threshold, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
기본값은 80% 이다.
다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.
minimum-container-ttl-duration, 종료된 컨테이너가 가비지 수집
되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
maximum-dead-containers-per-container, 컨테이너가 보유할 수 있는 오래된
인스턴스의 최대 수. 기본 값은 1 이다.
maximum-dead-containers, 글로벌하게 보유 할 컨테이너의 최대 오래된 인스턴스의 최대 수.
기본 값은 -1이며, 이 경우 인스턴스 수의 제한은 없다.
컨테이너들은 유용성이 만료되기 이전에도 가비지 수집이 될 수 있다. 이러한 컨테이너들은
문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
1개의 죽은 컨테이너가 허용될 수 있도록 maximum-dead-containers-per-container
값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 maximum-dead-containers
의 값도 상대적으로 더 큰 값을 권장한다.
자세한 내용은 해당 이슈를 참고한다.
사용 중단(Deprecation)
문서에 있는 몇 가지 kubelet의 가비지 수집 특징은 향후에 kubelet 축출(eviction) 기능으로 대체될 예정이다.
쿠버네티스 사용자는 보통 처음 두 가지 유형 외의 것은 걱정할 필요없다.
클러스터 관리자는 일반적으로 후자의 유형이 올바르게 구성되었는지 확인한다.
요청을 리다이렉트하기
프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다.
3.11.8 - 애드온 설치
주의:
이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.
Antrea는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다.
Calico는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
Canal은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
Cilium은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
CNI-Genie를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
Contiv는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 오픈소스이다. 인스톨러는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
Contrail은 Tungsten Fabric을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
Multus는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다.
OVN-Kubernetes는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 OVN(Open Virtual Network)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다.
OVN4NFV-K8S-Plugin은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
NSX-T 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
Nuage는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
Romana는 네트워크폴리시 API도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 여기에 있다.
Weave Net은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
서비스 검색
CoreDNS는 유연하고 확장 가능한 DNS 서버로, 파드를 위한 클러스터 내 DNS로 설치할 수 있다.
쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로
쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가
거의 없다.
이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다.
쿠버네티스 클러스터를 업무 환경의 요구에 맞게
조정하는 방법을 이해하려는 클러스터 운영자를 대상으로 한다.
잠재적인 플랫폼 개발자 또는 쿠버네티스 프로젝트 컨트리뷰터인 개발자에게도
어떤 익스텐션(extension) 포인트와 패턴이 있는지,
그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다.
개요
사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 구성 과 추가 프로그램이나 서비스 실행과 관련된 익스텐션 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
구성
구성 파일 및 플래그 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
리소스쿼터, 파드시큐리티폴리시(PodSecurityPolicy), 네트워크폴리시 및 역할 기반 접근 제어(RBAC)와 같은 빌트인 정책 API(built-in Policy API) 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 정의된 지원 정책을 사용할 수 있다. 이러한 이유로 인해 구성 파일 과 플래그 보다 선호된다.
익스텐션
익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다.
이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다.
대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다.
결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고
새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다.
익스텐션 패턴
쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다.
쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다.
자동화 는 클러스터 상에서 또는 클러스터 밖에서 실행할 수 있다. 이 문서의 지침에 따라
고가용성과 강력한 자동화를 작성할 수 있다.
자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든
쿠버네티스 클러스터에서 작동한다.
쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 컨트롤러 패턴이라고 한다.
컨트롤러는 일반적으로 오브젝트의 .spec을 읽고, 가능한 경우 수행한 다음
오브젝트의 .status를 업데이트 한다.
컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고
원격 서비스를 호출할 때 이를 웹훅(Webhook) 이라고 한다. 원격 서비스를
웹훅 백엔드 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을
추가한다.
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
바이너리 플러그인 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
바이너리 플러그인은 kubelet(예:
Flex Volume 플러그인과
네트워크 플러그인)과
kubectl에서
사용한다.
아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
보여주는 다이어그램이다.
익스텐션 포인트
이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
사용자는 종종 kubectl을 사용하여 쿠버네티스 API와 상호 작용한다. Kubectl 플러그인은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 API 접근 익스텐션 섹션에 설명되어 있다.
apiserver는 다양한 종류의 리소스 를 제공한다. pods와 같은 빌트인 리소스 종류 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, 커스텀 리소스 섹션에 설명된 대로 커스텀 리소스 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 스케줄러 익스텐션 섹션에 설명되어 있다.
쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. 네트워크 플러그인을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 스토리지 플러그인을 통해 지원될 수 있다.
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
API 익스텐션
사용자 정의 유형
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 kubectl 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다.
사용자 정의 리소스 API와 컨트롤 루프의 조합을 오퍼레이터(operator) 패턴이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
빌트인 리소스 변경
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다.
API 접근 익스텐션
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 쿠버네티스 API에 대한 접근 제어를 참고하길 바란다.
이러한 각 단계는 익스텐션 포인트를 제공한다.
쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 인증 설명서에 설명되어 있다.
쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 인증 웹훅 방법을 제공한다.
인가
인가은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 인가 웹훅을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
동적 어드미션 컨트롤
요청이 승인된 후, 쓰기 작업인 경우 어드미션 컨트롤 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다.
쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로
쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가
거의 없다.
이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다.
쿠버네티스 클러스터를 업무 환경의 요구에 맞게
조정하는 방법을 이해하려는 클러스터 운영자를
대상으로 한다.
잠재적인 플랫폼 개발자 또는
쿠버네티스 프로젝트 컨트리뷰터인 개발자에게도
어떤 익스텐션 포인트와 패턴이 있는지,
그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다.
개요
사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 구성 과 추가 프로그램이나 서비스 실행과 관련된 익스텐션 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
구성
구성 파일 및 플래그 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
리소스쿼터, PodSecurityPolicy, 네트워크폴리시 및 역할 기반 접근 제어(RBAC)와 같은 빌트인 정책 API(built-in Policy API) 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 정의된 지원 정책을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다.
익스텐션(Extension)
익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다.
이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다.
대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다.
결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고
새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다.
익스텐션 패턴
쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다.
쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다.
자동화 는 클러스터 상에서 또는 클러스터 밖에서 실행할 수 있다. 이 문서의 지침에 따라
고가용성과 강력한 자동화를 작성할 수 있다.
자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든
쿠버네티스 클러스터에서 작동한다.
쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 컨트롤러 패턴이라고 한다.
컨트롤러는 일반적으로 오브젝트의 .spec을 읽고, 가능한 경우 수행한 다음
오브젝트의 .status를 업데이트 한다.
컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고
원격 서비스를 호출할 때 이를 웹훅(Webhook) 이라고 한다. 원격 서비스를
웹훅 백엔드 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을
추가한다.
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
바이너리 플러그인 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
바이너리 플러그인은 kubelet(예:
Flex 볼륨 플러그인과
네트워크 플러그인)과
kubectl에서
사용한다.
아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
보여주는 다이어그램이다.
익스텐션 포인트
이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
사용자는 종종 kubectl을 사용하여 쿠버네티스 API와 상호 작용한다. Kubectl 플러그인은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 API 접근 익스텐션 섹션에 설명되어 있다.
apiserver는 다양한 종류의 리소스 를 제공한다. pods와 같은 빌트인 리소스 종류 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, 커스텀 리소스 섹션에 설명된 대로 커스텀 리소스 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 스케줄러 익스텐션 섹션에 설명되어 있다.
쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. 네트워크 플러그인을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 스토리지 플러그인을 통해 지원될 수 있다.
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
API 익스텐션
사용자 정의 유형
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 kubectl과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다.
사용자 정의 리소스 API와 컨트롤 루프의 조합을 오퍼레이터(operator) 패턴이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
빌트인 리소스 변경
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다.
API 접근 익스텐션
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 쿠버네티스 API에 대한 접근 제어를 참고하길 바란다.
이러한 각 단계는 익스텐션 포인트를 제공한다.
쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 인증 설명서에 설명되어 있다.
쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 인증 웹훅 방법을 제공한다.
인가
인가은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 인가 웹훅을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
동적 어드미션 컨트롤
요청이 승인된 후, 쓰기 작업인 경우 어드미션 컨트롤 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다.
애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다.
APIService를 구현하는 가장 일반적인 방법은 클러스터 내에 실행되고 있는 파드에서 extension API server 를 실행하는 것이다. extension API server를 사용해서 클러스터의 리소스를 관리하는 경우 extension API server("extension-apiserver" 라고도 한다)는 일반적으로 하나 이상의 컨트롤러와 쌍을 이룬다. apiserver-builder 라이브러리는 extension API server와 연관된 컨틀로러에 대한 스켈레톤을 제공한다.
응답 레이턴시
Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮아야 한다.
kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.
extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다.
커스텀 리소스 는 쿠버네티스 API의 익스텐션이다. 이 페이지에서는 쿠버네티스 클러스터에
커스텀 리소스를 추가할 시기와 독립형 서비스를 사용하는 시기에 대해 설명한다. 커스텀 리소스를
추가하는 두 가지 방법과 이들 중에서 선택하는 방법에 대해 설명한다.
커스텀 리소스
리소스 는 쿠버네티스 API에서 특정 종류의
API 오브젝트 모음을 저장하는 엔드포인트이다. 예를 들어 빌트인 파드 리소스에는 파드 오브젝트 모음이 포함되어 있다.
커스텀 리소스 는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시
사용할 수 있는 것은 아니다. 이는 특정 쿠버네티스 설치에 수정이 가해졌음을 나타낸다. 그러나
많은 핵심 쿠버네티스 기능은 이제 커스텀 리소스를 사용하여 구축되어, 쿠버네티스를 더욱 모듈화한다.
동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며
클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다.
커스텀 리소스가 설치되면 사용자는 파드 와 같은 빌트인 리소스와 마찬가지로
kubectl을 사용하여 해당 오브젝트를 생성하고
접근할 수 있다.
커스텀 컨트롤러
자체적으로 커스텀 리소스를 사용하면 구조화된 데이터를 저장하고 검색할 수 있다.
커스텀 리소스를 커스텀 컨트롤러 와 결합하면, 커스텀 리소스가 진정한
선언적(declarative) API 를 제공하게 된다.
선언적 API는 리소스의 의도한 상태를
선언 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트의 현재 상태를 의도한 상태와
동기화 상태로 유지하려고 한다. 컨트롤러는 구조화된 데이터를 사용자가
원하는 상태의 레코드로 해석하고 지속적으로
이 상태를 유지한다.
클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고
업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만
커스텀 리소스와 결합할 때 특히 효과적이다.
오퍼레이터 패턴은 사용자 정의
리소스와 커스텀 컨트롤러를 결합한다. 커스텀 컨트롤러를 사용하여 특정 애플리케이션에 대한 도메인 지식을
쿠버네티스 API의 익스텐션으로 인코딩할 수 있다.
다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자.
쿠버네티스 클라이언트 라이브러리 및 CLI를 사용하여 새 리소스를 만들고 업데이트하려고 한다.
kubectl 의 최상위 지원을 원한다. 예: kubectl get my-object object-name.
새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를 구축하려고 한다.
오브젝트의 업데이트를 처리하는 자동화를 작성하려고 한다.
.spec, .status 및 .metadata와 같은 쿠버네티스 API 규칙을 사용하려고 한다.
제어된 리소스의 콜렉션 또는 다른 리소스의 요약에 대한 오브젝트가 되기를 원한다.
커스텀 리소스 추가
쿠버네티스는 클러스터에 커스텀 리소스를 추가하는 두 가지 방법을 제공한다.
CRD는 간단하며 프로그래밍 없이 만들 수 있다.
API 애그리게이션에는 프로그래밍이 필요하지만, 데이터 저장 방법 및 API 버전 간 변환과 같은 API 동작을 보다 강력하게 제어할 수 있다.
쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 사용의 용이성이나 유연성이 저하되지 않는다.
애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 API 애그리게이션(AA)이라고 한다. 사용자에게는 쿠버네티스 API가 확장된 것으로 나타난다.
CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API 애그리게이션을 이해할 필요는 없다.
설치 방법에 관계없이 새 리소스는 커스텀 리소스라고 하며 빌트인 쿠버네티스 리소스(파드 등)와 구별된다.
커스텀리소스데피니션
커스텀리소스데피니션
API 리소스를 사용하면 커스텀 리소스를 정의할 수 있다.
CRD 오브젝트를 정의하면 지정한 이름과 스키마를 사용하여 새 커스텀 리소스가 만들어진다.
쿠버네티스 API는 커스텀 리소스의 스토리지를 제공하고 처리한다.
CRD 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
따라서 커스텀 리소스를 처리하기 위해 자신의 API 서버를 작성할 수 없지만
구현의 일반적인 특성으로 인해
API 서버 애그리게이션보다 유연성이 떨어진다.
새 커스텀 리소스를 등록하고 새 리소스 타입의 인스턴스에 대해 작업하고
컨트롤러를 사용하여 이벤트를 처리하는 방법에 대한 예제는
커스텀 컨트롤러 예제를 참고한다.
API 서버 애그리게이션
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 파드 및 서비스 와 같은 빌트인 리소스를 처리하고, 일반적으로 CRD를 통해 커스텀 리소스를 처리할 수 있다.
애그리게이션 레이어를 사용하면 자체 독립형 API 서버를
작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 사용자에게 위임하여
모든 클라이언트가 사용할 수 있게 한다.
커스텀 리소스를 추가할 방법 선택
CRD는 사용하기가 더 쉽다. 애그리게이트 API가 더 유연하다. 자신의 요구에 가장 잘 맞는 방법을 선택하자.
일반적으로 CRD는 다음과 같은 경우에 적합하다.
필드가 몇 개 되지 않는다
회사 내에서 또는 소규모 오픈소스 프로젝트의 일부인(상용 제품이 아닌) 리소스를 사용하고 있다.
사용 편의성 비교
CRD는 애그리게이트 API보다 생성하기가 쉽다.
CRD
애그리게이트 API
프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다.
Go로 프로그래밍하고 바이너리와 이미지를 빌드해야 한다.
실행할 추가 서비스가 없다. CR은 API 서버에서 처리한다.
추가 서비스를 생성하면 실패할 수 있다.
CRD가 생성된 후에는 지속적인 지원이 없다. 모든 버그 픽스는 일반적인 쿠버네티스 마스터 업그레이드의 일부로 선택된다.
업스트림에서 버그 픽스를 주기적으로 선택하고 애그리게이트 API 서버를 다시 빌드하고 업데이트해야 할 수 있다.
여러 버전의 API를 처리할 필요가 없다. 예를 들어, 이 리소스에 대한 클라이언트를 제어할 때 API와 동기화하여 업그레이드할 수 있다.
인터넷에 공유할 익스텐션을 개발할 때와 같이 여러 버전의 API를 처리해야 한다.
고급 기능 및 유연성
애그리게이트 API는 보다 고급 API 기능과 스토리지 레이어와 같은 다른 기능의 사용자 정의를 제공한다.
기능
설명
CRD
애그리게이트 API
유효성 검사
사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다.
새로운 엔드포인트는 Content-Type: application/strategic-merge-patch+json 형식의 PATCH를 지원한다. 로컬 및 서버 양쪽에서 수정할 수도 있는 오브젝트를 업데이트하는 데 유용하다. 자세한 내용은 "kubectl 패치를 사용한 API 오브젝트 업데이트"를 참고한다.
아니오
예
프로토콜 버퍼
새로운 리소스는 프로토콜 버퍼를 사용하려는 클라이언트를 지원한다.
아니오
예
OpenAPI 스키마
서버에서 동적으로 가져올 수 있는 타입에 대한 OpenAPI(스웨거(swagger)) 스키마가 있는가? 허용된 필드만 설정하여 맞춤법이 틀린 필드 이름으로부터 사용자를 보호하는가? 타입이 적용되는가(즉, string 필드에 int를 넣지 않는가?)
CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플랫폼 외부에서 구현하는 것과 비교하여 API에 대한 많은 기능이 제공된다.
기능
설명
CRUD
새로운 엔드포인트는 HTTP 및 kubectl을 통해 CRUD 기본 작업을 지원한다.
감시
새로운 엔드포인트는 HTTP를 통해 쿠버네티스 감시 작업을 지원한다.
디스커버리
kubectl 및 대시보드와 같은 클라이언트는 리소스에 대해 목록, 표시 및 필드 수정 작업을 자동으로 제공한다.
json-patch
새로운 엔드포인트는 Content-Type: application/json-patch+json 형식의 PATCH를 지원한다.
merge-patch
새로운 엔드포인트는 Content-Type: application/merge-patch+json 형식의 PATCH를 지원한다.
HTTPS
새로운 엔드포인트는 HTTPS를 사용한다.
빌트인 인증
익스텐션에 대한 접근은 인증을 위해 기본 API 서버(애그리게이션 레이어)를 사용한다.
빌트인 권한 부여
익스텐션에 접근하면 기본 API 서버(예: RBAC)에서 사용하는 권한을 재사용할 수 있다.
Finalizer
외부 정리가 발생할 때까지 익스텐션 리소스의 삭제를 차단한다.
어드미션 웹훅
생성/업데이트/삭제 작업 중에 기본값을 설정하고 익스텐션 리소스의 유효성 검사를 한다.
UI/CLI 디스플레이
Kubectl, 대시보드는 익스텐션 리소스를 표시할 수 있다.
설정하지 않음(unset)과 비어있음(empty)
클라이언트는 값이 없는 필드 중에서 설정되지 않은 필드를 구별할 수 있다.
클라이언트 라이브러리 생성
쿠버네티스는 일반 클라이언트 라이브러리와 타입별 클라이언트 라이브러리를 생성하는 도구를 제공한다.
레이블 및 어노테이션
공통 메타데이터는 핵심 및 커스텀 리소스를 수정하는 방법을 알고 있는 도구이다.
커스텀 리소스 설치 준비
클러스터에 커스텀 리소스를 추가하기 전에 알아야 할 몇 가지 사항이 있다.
써드파티 코드 및 새로운 장애 포인트
CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다.
애그리게이트 API 서버를 설치하려면 항상 새 디플로이먼트를 실행해야 한다.
스토리지
커스텀 리소스는 컨피그맵과 동일한 방식으로 스토리지 공간을 사용한다. 너무 많은 커스텀 리소스를 생성하면 API 서버의 스토리지 공간이 과부하될 수 있다.
애그리게이트 API 서버는 기본 API 서버와 동일한 스토리지를 사용할 수 있으며 이 경우 동일한 경고가 적용된다.
인증, 권한 부여 및 감사
CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부여 및 감사 로깅을 사용한다.
권한 부여에 RBAC를 사용하는 경우 대부분의 RBAC 역할은 새로운 리소스에 대한 접근 권한을 부여하지 않는다(클러스터 관리자 역할 또는 와일드 카드 규칙으로 생성된 역할 제외). 새로운 리소스에 대한 접근 권한을 명시적으로 부여해야 한다. CRD 및 애그리게이트 API는 종종 추가하는 타입에 대한 새로운 역할 정의와 함께 제공된다.
애그리게이트 API 서버는 기본 API 서버와 동일한 인증, 권한 부여 및 감사를 사용하거나 사용하지 않을 수 있다.
커스텀 리소스에 접근
쿠버네티스 클라이언트 라이브러리를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. Go 와 python 클라이언트 라이브러리가 지원한다.
커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다.
kubectl
쿠버네티스 동적 클라이언트
작성한 REST 클라이언트
쿠버네티스 클라이언트 생성 도구를 사용하여 생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는 CRD 또는 AA와 함께 클라이언트를 제공할 수 있다).
오퍼레이터(Operator)는
사용자 정의 리소스를
사용하여 애플리케이션 및 해당 컴포넌트를 관리하는 쿠버네티스의 소프트웨어 익스텐션이다. 오퍼레이터는
쿠버네티스 원칙, 특히 컨트롤 루프를 따른다.
동기 부여
오퍼레이터 패턴은 서비스 또는 서비스 셋을 관리하는 운영자의
주요 목표를 포착하는 것을 목표로 한다. 특정 애플리케이션 및
서비스를 돌보는 운영자는 시스템의 작동 방식, 배포 방법 및 문제가 있는 경우
대처 방법에 대해 깊이 알고 있다.
쿠버네티스에서 워크로드를 실행하는 사람들은 종종 반복 가능한 작업을 처리하기 위해
자동화를 사용하는 것을 좋아한다. 오퍼레이터 패턴은 쿠버네티스 자체가 제공하는 것 이상의
작업을 자동화하기 위해 코드를 작성하는 방법을 포착한다.
쿠버네티스의 오퍼레이터
쿠버네티스는 자동화를 위해 설계되었다. 기본적으로 쿠버네티스의 중추를 통해 많은
빌트인 자동화 기능을 사용할 수 있다. 쿠버네티스를 사용하여 워크로드 배포
및 실행을 자동화할 수 있고, 또한 쿠버네티스가 수행하는 방식을
자동화할 수 있다.
쿠버네티스의 컨트롤러
개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을
확장할 수 있다.
오퍼레이터는 사용자 정의 리소스의
컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다.
오퍼레이터 예시
오퍼레이터를 사용하여 자동화할 수 있는 몇 가지 사항은 다음과 같다.
주문형 애플리케이션 배포
해당 애플리케이션의 상태를 백업하고 복원
데이터베이스 스키마 또는 추가 구성 설정과 같은 관련 변경 사항에 따른
애플리케이션 코드 업그레이드 처리
쿠버네티스 API를 지원하지 않는 애플리케이션에 서비스를
게시하여 검색을 지원
클러스터의 전체 또는 일부에서 장애를 시뮬레이션하여 가용성 테스트
내부 멤버 선출 절차없이 분산 애플리케이션의
리더를 선택
오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 자세한 예는
다음과 같다.
클러스터에 구성할 수 있는 SampleDB라는 사용자 정의 리소스.
오퍼레이터의 컨트롤러 부분이 포함된 파드의 실행을
보장하는 디플로이먼트.
오퍼레이터 코드의 컨테이너 이미지.
컨트롤 플레인을 쿼리하여 어떤 SampleDB 리소스가 구성되어 있는지
알아내는 컨트롤러 코드.
오퍼레이터의 핵심은 API 서버에 구성된 리소스와 현재 상태를
일치시키는 방법을 알려주는 코드이다.
새 SampleDB를 추가하면 오퍼레이터는 퍼시스턴트볼륨클레임을
설정하여 내구성있는 데이터베이스 스토리지, SampleDB를 실행하는 스테이트풀셋 및
초기 구성을 처리하는 잡을 제공한다.
SampleDB를 삭제하면 오퍼레이터는 스냅샷을 생성한 다음 스테이트풀셋과 볼륨도
제거되었는지 확인한다.
오퍼레이터는 정기적인 데이터베이스 백업도 관리한다. 오퍼레이터는 각 SampleDB
리소스에 대해 데이터베이스에 연결하고 백업을 수행할 수 있는 파드를 생성하는
시기를 결정한다. 이 파드는 데이터베이스 연결 세부 정보 및 자격 증명이 있는
컨피그맵 및 / 또는 시크릿에 의존한다.
오퍼레이터는 관리하는 리소스에 견고한 자동화를 제공하는 것을 목표로 하기 때문에
추가 지원 코드가 있다. 이 예제에서 코드는 데이터베이스가 이전 버전을 실행 중인지
확인하고, 업그레이드된 경우 이를 업그레이드하는
잡 오브젝트를 생성한다.
오퍼레이터 배포
오퍼레이터를 배포하는 가장 일반적인 방법은
커스텀 리소스 데피니션의 정의 및 연관된 컨트롤러를 클러스터에 추가하는 것이다.
컨테이너화된 애플리케이션을 실행하는 것처럼
컨트롤러는 일반적으로 컨트롤 플레인
외부에서 실행된다.
예를 들어 클러스터에서 컨트롤러를 디플로이먼트로 실행할 수 있다.
오퍼레이터 사용
오퍼레이터가 배포되면 오퍼레이터가 사용하는 리소스의 종류를 추가, 수정 또는
삭제하여 사용한다. 위의 예에 따라 오퍼레이터 자체에 대한
디플로이먼트를 설정한 후 다음을 수행한다.
kubectl get SampleDB # 구성된 데이터베이스 찾기
kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하기
…이것으로 끝이다! 오퍼레이터는 변경 사항을 적용하고 기존 서비스를
양호한 상태로 유지한다.
자신만의 오퍼레이터 작성
에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면
직접 코딩할 수 있다.
또한 쿠버네티스 API의 클라이언트
역할을 할 수 있는 모든 언어 / 런타임을 사용하여 오퍼레이터(즉, 컨트롤러)를 구현한다.
다음은 클라우드 네이티브 오퍼레이터를 작성하는 데 사용할 수 있는
몇 가지 라이브러리와 도구들이다.
주의:
이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.
Kubenet 플러그인: bridge 와 host-local CNI 플러그인을 사용하여 기본 cbr0 구현한다.
설치
kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(CRI는 자체 CNI 플러그인을 관리하므로 도커에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
cni-bin-dir: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
network-plugin: cni-bin-dir 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다.
네트워크 플러그인 요구 사항
파드 네트워킹을 구성하고 정리하기 위해 NetworkPlugin 인터페이스를 제공하는 것 외에도, 플러그인은 kube-proxy에 대한 특정 지원이 필요할 수 있다. iptables 프록시는 분명히 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다. 예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 net/bridge/bridge-nf-call-iptables sysctl을 1 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. 플러그인이 리눅스 브리지를 사용하지 않는 경우(그러나 Open vSwitch나 다른 메커니즘과 같은 기능을 사용함) 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 noop 플러그인이 사용되며, net/bridge/bridge-nf-call-iptables=1 을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
CNI
CNI 플러그인은 Kubelet에 --network-plugin=cni 커맨드라인 옵션을 전달하여 선택된다. Kubelet은 --cni-conf-dir(기본값은 /etc/cni/net.d)에서 파일을 읽고 해당 파일의 CNI 구성을 사용하여 각 파드의 네트워크를 설정한다. CNI 구성 파일은 CNI 명세와 일치해야 하며, 구성에서 참조하는 필수 CNI 플러그인은 --cni-bin-dir(기본값은 /opt/cni/bin)에 있어야 한다.
디렉터리에 여러 CNI 구성 파일이 있는 경우, kubelet은 이름별 알파벳 순으로 구성 파일을 사용한다.
구성 파일에 지정된 CNI 플러그인 외에도, 쿠버네티스는 최소 0.2.0 버전의 표준 CNI lo 플러그인이 필요하다.
hostPort 지원
CNI 네트워킹 플러그인은 hostPort 를 지원한다. CNI 플러그인 팀이 제공하는 공식 포트맵(portmap)
플러그인을 사용하거나 portMapping 기능이 있는 자체 플러그인을 사용할 수 있다.
hostPort 지원을 사용하려면, cni-conf-dir 에 portMappings capability 를 지정해야 한다.
예를 들면 다음과 같다.
Kubenet은 리눅스에서만 사용할 수 있는 매우 기본적이고, 간단한 네트워크 플러그인이다. 그 자체로는, 크로스-노드 네트워킹 또는 네트워크 정책과 같은 고급 기능을 구현하지 않는다. 일반적으로 노드 간, 또는 단일 노드 환경에서 통신을 위한 라우팅 규칙을 설정하는 클라우드 제공자와 함께 사용된다.
Kubenet은 cbr0 라는 리눅스 브리지를 만들고 각 쌍의 호스트 끝이 cbr0 에 연결된 각 파드에 대한 veth 쌍을 만든다. 쌍의 파드 끝에는 구성 또는 컨트롤러 관리자를 통해 노드에 할당된 범위 내에서 할당된 IP 주소가 지정된다. cbr0 에는 호스트에서 활성화된 일반 인터페이스의 가장 작은 MTU와 일치하는 MTU가 지정된다.
플러그인에는 몇 가지 사항이 필요하다.
표준 CNI bridge, lo 및 host-local 플러그인은 최소 0.2.0 버전이 필요하다. Kubenet은 먼저 /opt/cni/bin 에서 검색한다. 추가 검색 경로를 제공하려면 cni-bin-dir 을 지정한다. 처음 검색된 디렉터리가 적용된다.
플러그인을 활성화하려면 Kubelet을 --network-plugin=kubenet 인수와 함께 실행해야 한다.
Kubelet은 --non-masquerade-cidr=<clusterCidr> 인수와 함께 실행하여 이 범위 밖 IP로의 트래픽이 IP 마스커레이드(masquerade)를 사용하도록 해야 한다.
--pod-cidr kubelet 커맨드라인 옵션 또는 --allocate-node-cidrs=true --cluster-cidr=<cidr> 컨트롤러 관리자 커맨드라인 옵션을 통해 노드에 IP 서브넷을 할당해야 한다.
MTU 사용자 정의 (kubenet 사용)
최상의 네트워킹 성능을 얻으려면 MTU를 항상 올바르게 구성해야 한다. 네트워크 플러그인은 일반적으로 합리적인 MTU를
유추하려고 시도하지만, 때로는 로직에 따라 최적의 MTU가 지정되지 않는다. 예를 들어,
도커 브리지나 다른 인터페이스에 작은 MTU가 지정되어 있으면, kubenet은 현재 해당 MTU를 선택한다. 또는
IPSEC 캡슐화를 사용하는 경우, MTU를 줄여야 하며, 이 계산은 대부분의
네트워크 플러그인에서 범위를 벗어난다.
필요한 경우, network-plugin-mtu kubelet 옵션을 사용하여 MTU를 명시 적으로 지정할 수 있다. 예를 들어,
AWS에서 eth0 MTU는 일반적으로 9001이므로, --network-plugin-mtu=9001 을 지정할 수 있다. IPSEC를 사용하는 경우
캡슐화 오버헤드를 허용하도록 --network-plugin-mtu=8873 과 같이 IPSEC을 줄일 수 있다.
이 옵션은 네트워크 플러그인에 제공된다. 현재 kubenet만 network-plugin-mtu 를 지원한다.
용법 요약
--network-plugin=cni 는 --cni-bin-dir(기본값 /opt/cni/bin)에 있는 실제 CNI 플러그인 바이너리와 --cni-conf-dir(기본값 /etc/cni/net.d)에 있는 CNI 플러그인 구성과 함께 cni 네트워크 플러그인을 사용하도록 지정한다.
--network-plugin=kubenet 은 /opt/cni/bin 또는 cni-bin-dir 에 있는 CNI bridge, lo 및 host-local 플러그인과 함께 kubenet 네트워크 플러그인을 사용하도록 지정한다.
현재 kubenet 네트워크 플러그인에서만 사용하는 --network-plugin-mtu=9001 은 사용할 MTU를 지정한다.
3.12.4.2 - 장치 플러그인
GPU, NIC, FPGA, InfiniBand 및 공급 업체별 설정이 필요한 유사한 리소스를 위한 플러그인을 구현하는데 쿠버네티스 장치 플러그인 프레임워크를 사용한다.
공급 업체는 쿠버네티스 자체의 코드를 커스터마이징하는 대신, 수동 또는
데몬셋으로 배포하는 장치 플러그인을 구현할 수 있다.
대상이 되는 장치에는 GPU, 고성능 NIC, FPGA, InfiniBand 어댑터
및 공급 업체별 초기화 및 설정이 필요할 수 있는 기타 유사한 컴퓨팅 리소스가
포함된다.
장치 플러그인 등록
kubelet은 Registration gRPC 서비스를 노출시킨다.
service Registration {
rpc Register(RegisterRequest) returns (Empty) {}
}
장치 플러그인은 이 gRPC 서비스를 통해 kubelet에 자체 등록할 수 있다.
등록하는 동안, 장치 플러그인은 다음을 보내야 한다.
유닉스 소켓의 이름.
빌드된 장치 플러그인 API 버전.
알리려는 ResourceName. 여기서 ResourceName 은
확장된 리소스 네이밍 체계를
vendor-domain/resourcetype 의 형식으로 따라야 한다.
(예를 들어, NVIDIA GPU는 nvidia.com/gpu 로 알려진다.)
성공적으로 등록하고 나면, 장치 플러그인은 kubelet이 관리하는
장치 목록을 전송한 다음, kubelet은 kubelet 노드 상태 업데이트의 일부로
해당 자원을 API 서버에 알리는 역할을 한다.
예를 들어, 장치 플러그인이 kubelet에 hardware-vendor.example/foo 를 등록하고
노드에 두 개의 정상 장치를 보고하고 나면, 노드 상태가 업데이트되어
노드에 2개의 "Foo" 장치가 설치되어 사용 가능함을 알릴 수 있다.
그러고 나면, 사용자가
컨테이너 명세에 있는 장치를 요청할 수 있다.
다만, 다른 종류의 리소스를 요청하는 것이므로 다음과 같은 제한이 있다.
확장된 리소스는 정수(integer) 형태만 지원되며 오버커밋(overcommit) 될 수 없다.
컨테이너간에 장치를 공유할 수 없다.
쿠버네티스 클러스터가 특정 노드에서 hardware-vendor.example/foo 리소스를 알리는 장치 플러그인을 실행한다고
가정해 보자. 다음은 데모 워크로드를 실행하기 위해 이 리소스를 요청하는 파드의 예이다.
---apiVersion:v1kind:Podmetadata:name:demo-podspec:containers:- name:demo-container-1image:k8s.gcr.io/pause:2.0resources:limits:hardware-vendor.example/foo:2## 이 파드는 2개의 hardware-vendor.example/foo 장치가 필요하며# 해당 요구를 충족할 수 있는 노드에만# 예약될 수 있다.## 노드에 2개 이상의 사용 가능한 장치가 있는 경우# 나머지는 다른 파드에서 사용할 수 있다.
장치 플러그인 구현
장치 플러그인의 일반적인 워크플로우에는 다음 단계가 포함된다.
초기화. 이 단계에서, 장치 플러그인은 공급 업체별 초기화 및 설정을 수행하여
장치가 준비 상태에 있는지 확인한다.
플러그인은 다음의 인터페이스를 구현하는 호스트 경로 /var/lib/kubelet/device-plugins/
아래에 유닉스 소켓과 함께 gRPC 서비스를 시작한다.
service DevicePlugin {
// GetDevicePluginOptions는 장치 관리자와 통신할 옵션을 반환한다.
rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
// ListAndWatch는 장치 목록 스트림을 반환한다.
// 장치 상태가 변경되거나 장치가 사라질 때마다, ListAndWatch는
// 새 목록을 반환한다.
rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
// 컨테이너를 생성하는 동안 Allocate가 호출되어 장치
// 플러그인이 장치별 작업을 실행하고 Kubelet에 장치를
// 컨테이너에서 사용할 수 있도록 하는 단계를 지시할 수 있다.
rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
// GetPreferredAllocation은 사용 가능한 장치 목록에서 할당할
// 기본 장치 집합을 반환한다. 그 결과로 반환된 선호하는 할당은
// devicemanager가 궁극적으로 수행하는 할당이 되는 것을 보장하지
// 않는다. 가능한 경우 devicemanager가 정보에 입각한 할당 결정을
// 내릴 수 있도록 설계되었다.
rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
// PreStartContainer는 등록 단계에서 장치 플러그인에 의해 표시되면 각 컨테이너가
// 시작되기 전에 호출된다. 장치 플러그인은 장치를 컨테이너에서 사용할 수 있도록 하기 전에
// 장치 재설정과 같은 장치별 작업을 실행할 수 있다.
rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
}
참고:GetPreferredAllocation() 또는 PreStartContainer() 에 대한 유용한 구현을
제공하기 위해 플러그인이 필요하지 않다. 이러한 호출(있는 경우) 중
사용할 수 있는 경우를 나타내는 플래그는 GetDevicePluginOptions()
호출에 의해 다시 전송된 DevicePluginOptions 메시지에 설정되어야 한다. kubelet 은
항상 GetDevicePluginOptions() 를 호출하여 사용할 수 있는
선택적 함수를 확인한 후 직접 호출한다.
플러그인은 호스트 경로 /var/lib/kubelet/device-plugins/kubelet.sock 에서
유닉스 소켓을 통해 kubelet에 직접 등록한다.
성공적으로 등록하고 나면, 장치 플러그인은 서빙(serving) 모드에서 실행되며, 그 동안 플러그인은 장치 상태를
모니터링하고 장치 상태 변경 시 kubelet에 다시 보고한다.
또한 gRPC 요청 Allocate 를 담당한다. Allocate 하는 동안, 장치 플러그인은
GPU 정리 또는 QRNG 초기화와 같은 장치별 준비를 수행할 수 있다.
작업이 성공하면, 장치 플러그인은 할당된 장치에 접근하기 위한 컨테이너 런타임 구성이 포함된
AllocateResponse 를 반환한다. kubelet은 이 정보를
컨테이너 런타임에 전달한다.
kubelet 재시작 처리
장치 플러그인은 일반적으로 kubelet의 재시작을 감지하고 새로운
kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 현재의 구현에서, 새 kubelet 인스턴스는 시작될 때
/var/lib/kubelet/device-plugins 아래에 있는 모든 기존의 유닉스 소켓을 삭제한다. 장치 플러그인은 유닉스 소켓의
삭제를 모니터링하고 이러한 이벤트가 발생하면 다시 자신을 등록할 수 있다.
장치 플러그인 배포
장치 플러그인을 데몬셋, 노드 운영 체제의 패키지
또는 수동으로 배포할 수 있다.
표준 디렉터리 /var/lib/kubelet/device-plugins 에는 특권을 가진 접근이 필요하므로,
장치 플러그인은 특권을 가진 보안 컨텍스트에서 실행해야 한다.
장치 플러그인을 데몬셋으로 배포하는 경우, 플러그인의
PodSpec에서
/var/lib/kubelet/device-plugins 를
볼륨으로 마운트해야 한다.
데몬셋 접근 방식을 선택하면 쿠버네티스를 사용하여 장치 플러그인의 파드를 노드에 배치하고,
장애 후 데몬 파드를 다시 시작하고, 업그레이드를 자동화할 수 있다.
API 호환성
쿠버네티스 장치 플러그인 지원은 베타 버전이다. 호환되지 않는 방식으로 안정화 전에 API가
변경될 수 있다. 프로젝트로서, 쿠버네티스는 장치 플러그인 개발자에게 다음 사항을 권장한다.
향후 릴리스에서 변경 사항을 확인하자.
이전/이후 버전과의 호환성을 위해 여러 버전의 장치 플러그인 API를 지원한다.
최신 장치 플러그인 API 버전의 쿠버네티스 릴리스로 업그레이드해야 하는 노드에서 DevicePlugins 기능을 활성화하고
장치 플러그인을 실행하는 경우, 이 노드를 업그레이드하기 전에
두 버전을 모두 지원하도록 장치 플러그인을 업그레이드한다. 이 방법을 사용하면
업그레이드 중에 장치 할당이 지속적으로 작동한다.
장치 플러그인 리소스 모니터링
FEATURE STATE:Kubernetes v1.15 [beta]
장치 플러그인에서 제공하는 리소스를 모니터링하려면, 모니터링 에이전트가
노드에서 사용 중인 장치 셋을 검색하고 메트릭과 연관될 컨테이너를 설명하는
메타데이터를 얻을 수 있어야 한다. 장치 모니터링 에이전트에 의해 노출된
프로메테우스 지표는
쿠버네티스 Instrumentation 가이드라인을 따라
pod, namespace 및 container 프로메테우스 레이블을 사용하여 컨테이너를 식별해야 한다.
kubelet은 gRPC 서비스를 제공하여 사용 중인 장치를 검색하고, 이러한 장치에 대한 메타데이터를
제공한다.
// PodResourcesLister는 kubelet에서 제공하는 서비스로, 노드의 포드 및 컨테이너가
// 사용한 노드 리소스에 대한 정보를 제공한다.
service PodResourcesLister {
rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
}
gRPC 서비스는 /var/lib/kubelet/pod-resources/kubelet.sock 의 유닉스 소켓을 통해 제공된다.
장치 플러그인 리소스에 대한 모니터링 에이전트는 데몬 또는 데몬셋으로 배포할 수 있다.
표준 디렉터리 /var/lib/kubelet/pod-resources 에는 특권을 가진 접근이 필요하므로, 모니터링
에이전트는 특권을 가진 보안 컨텍스트에서 실행해야 한다. 장치 모니터링 에이전트가
데몬셋으로 실행 중인 경우, 해당 장치 모니터링 에이전트의 PodSpec에서
/var/lib/kubelet/pod-resources 를
볼륨으로 마운트해야 한다.
"PodResources 서비스"를 지원하려면 KubeletPodResources기능 게이트를 활성화해야 한다.
토폴로지 관리자와 장치 플러그인 통합
FEATURE STATE:Kubernetes v1.18 [beta]
토폴로지 관리자는 Kubelet 컴포넌트로, 리소스를 토폴로지 정렬 방식으로 조정할 수 있다. 이를 위해, 장치 플러그인 API가 TopologyInfo 구조체를 포함하도록 확장되었다.
서비스 카탈로그는 쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록하는 확장 API이다.
서비스 생성 또는 관리에 대한 자세한 지식 없이도 서비스 브로커를 통해 외부의 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.
오픈 서비스 브로커 API 명세에 정의된 서비스 브로커는 AWS, GCP 또는 Azure와 같은 타사 클라우드 공급자에 의해 제공되고 관리되는 매니지드 서비스의 세트에 대한 엔드포인트다.
매니지드 서비스의 예로 Microsoft Azure Cloud Queue, Amazon Simple Quere Service, Google Cloud Pub/Sub이 있으나 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품일 수 있다.
클러스터 오퍼레이터는 서비스 카탈로그를 사용하여 서비스 브로커가 제공하는 매니지드 서비스 목록을 탐색하거나 매니지드 서비스 인스턴스를 프로비저닝하고, 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있도록 바인딩할 수 있다.
유스케이스 예제
한 애플리케이션 개발자가 쿠버네티스 클러스터 내에서 실행되는 애플리케이션 중 일부로 메시지 큐를 사용하기를 원한다.
그러나 그러한 서비스에 대한 설정과 관리에는 부담이 따른다.
다행히 서비스 브로커를 통해 메시지 큐를 매니지드 서비스로 제공하는 클라우드 공급자가 있다.
클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다.
따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다.
애플리케이션은 메시지 큐에 서비스로 접속할 수 있다.
아키텍처
서비스 카탈로그는 오픈 서비스 브로커 API를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다.
서비스 카탈로그는 servicecatalog.k8s.io API를 설치하고 다음 쿠버네티스 리소스를 제공한다.
ClusterServiceBroker: 서버 연결 세부 사항을 캡슐화한, 서비스 브로커의 클러스터 내부 대표.
이들은 클러스터 내에서 새로운 유형의 매니지드 서비스를 사용할 수 있도록 하려는 클러스터 운영자가 만들고 관리한다.
ClusterServiceClass: 특정 서비스 브로커가 제공하는 매니지드 서비스.
새로운 ClusterServiceBroker 리소스가 클러스터에 추가되면 서비스 카탈로그 컨트롤러는 서비스 브로커에 연결해서 사용 가능한 매니지드 서비스 목록을 얻는다. 그 다음 각 매니지드 서비스에 해당하는 새로운 ClusterServiceClass 리소스를 만든다.
ClusterServicePlan: 매니지드 서비스의 특별 요청. 예를 들어, 매니지드 서비스는 무료 혹은 유료 티어와 같이 사용 가능한 서로 다른 상품이 있거나, SSD 스토리지를 사용하거나 더 많은 리소스를 갖는 등 다른 구성 옵션을 가질 수 있다. ClusterServiceClass와 유사하게, 새로운 ClusterServiceBroker가 클러스터에 추가되면, 서비스 카탈로그는 각 매니지드 서비스에 사용 가능한 서비스 플랜에 해당하는 새로운 ClusterServicePlan 리소스를 작성한다.
ServiceInstance: ClusterServiceClass의 프로비저닝된 인스턴스.
클러스터 운영자가 하나 이상의 클러스터 애플리케이션에서 사용할 수 있도록 매니지드 서비스의 특정 인스턴스를 사용하기 위해 생성한다.
새로운 ServiceInstance리소스가 생성되면, 서비스 카탈로그 컨트롤러는 해당 서비스 브로커에 연결하여 서비스 인스턴스를 프로비저닝하도록 지시한다.
ServiceBinding: ServiceInstance에 대한 자격 증명에 액세스한다.
자신의 애플리케이션이 ServiceInstance를 사용하기를 원하는 클러스터 운영자가 이들을 생성한다.
서비스 카탈로그 컨트롤러는 생성 시 파드에 마운트될 수 있는 서비스 인스턴스에 대한 연결 세부 정보와 자격 증명이 포함된 쿠버네티스 '시크릿(secret)'을 생성한다.
클러스터 운영자는 서비스 카탈로그 API 리소스를 사용하여 매니지드 서비스를 프로비저닝하여 쿠버네티스 클러스터 내에서 사용할 수 있게 한다. 관련 단계는 다음과 같다.
서비스 브로커에서 사용 가능한 매니지드 서비스와 서비스 플랜을 나열.
매니지드 서비스의 새 인스턴스 프로비저닝.
연결 자격 증명을 반환하는 매니지드 서비스에 바인딩.
연결 자격 증명을 애플리케이션에 매핑.
매니지드 서비스와 서비스 플랜 나열
먼저, 클러스터 운영자는 servicecatalog.k8s.io 그룹 내에 ClusterServiceBroker 리소스를 생성해야 한다. 이 리소스는 서비스 브로커 엔드포인트에 접근하는데 필요한 URL과 연결 세부 사항을 포함한다.
다음은 ClusterServiceBroker 리소스 예시이다.
apiVersion:servicecatalog.k8s.io/v1beta1kind:ClusterServiceBrokermetadata:name:cloud-brokerspec:# 서비스 브로커의 엔드포인트를 가리킨다. (이 예시는 동작하지 않는 URL이다.)url:https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default###### bearer 토큰 정보 혹은 TLS용 caBundle과 같은# 서비스 브로커와 통신하는데 사용될 수 있는 값을 여기에 추가할 수 있다.#####
다음은 서비스 브로커에서 사용 가능한 매니지드 서비스와 플랜을 나열하는 단계를 설명하는 시퀀스 다이어그램이다.
ClusterServiceBroker 리소스가 서비스 카탈로그에 추가되면, 사용 가능한 서비스 목록에 대한 외부 서비스 브로커에 대한 호출을 발생시킨다.
서비스 브로커는 사용 가능한 매니지드 서비스 목록과 서비스 플랜 목록을 반환한다. 이 목록은 각각 로컬 ClusterServiceClass와 ClusterServicePlan 리소스로 캐시된다.
그런 다음 클러스터 운영자는 다음의 명령어를 사용하여 가용한 관리 서비스 목록을 얻을 수 있다.
kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
아래와 같은 형태의 서비스 이름 목록이 출력된다.
SERVICE NAME EXTERNAL NAME
4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service
... ...
또한 다음의 명령어를 사용하여 가용한 서비스 플랜을 볼 수 있다.
kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
아래와 같은 형태의 플랜 이름 목록이 출력된다.
PLAN NAME EXTERNAL NAME
86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name
... ...
새 인스턴스 프로비저닝
클러스터 운영자는 ServiceInstance 리소스를 생성하여 새 인스턴스 프로비저닝을 시작할 수 있다.
다음은 ServiceInstance 리소스의 예시이다.
apiVersion:servicecatalog.k8s.io/v1beta1kind:ServiceInstancemetadata:name:cloud-queue-instancenamespace:cloud-appsspec:# 이전에 반환된 서비스 중 하나를 참조clusterServiceClassExternalName:cloud-provider-serviceclusterServicePlanExternalName:service-plan-name###### 이곳에 서비스 브로커가 사용할 수 있는# 파라미터를 추가할 수 있다.#####
다음의 시퀀스 다이어그램은 매니지드 서비스의 새 인스턴스 프로비저닝과 관련된 일련의 단계를 보여준다.
ServiceInstance 리소스가 생성되면, 서비스 카탈로그는 서비스 인스턴스를 프로비저닝하기 위해 외부의 서비스 브로커 호출을 초기화한다.
서비스 브로커는 새로운 매니지드 서비스 인스턴스를 생성하고 HTTP 응답을 리턴한다.
그 후 클러스터 운영자는 인스턴스 상태가 준비되었는지 점검할 수 있다.
매니지드 서비스에 바인딩
새 인스턴스가 프로비저닝된 후, 클러스터 운영자는 애플리케이션이 서비스를 사용하는데 필요한 자격 증명을 얻기 위해 매니지드 서비스에 바인드해야 한다. 이것은 ServiceBinding 리소스를 생성하는 것으로 이루어진다.
다음은 ServiceBinding 리소스의 예시다.
apiVersion:servicecatalog.k8s.io/v1beta1kind:ServiceBindingmetadata:name:cloud-queue-bindingnamespace:cloud-appsspec:instanceRef:name:cloud-queue-instance###### 서비스 브로커가 사용할 수 있는 secretName, 서비스 어카운트 파라미터 등의# 추가 정보를 여기에 추가할 수 있다.#####
다음의 시퀀스 다이어그램은 매니지드 서비스 인스턴스에 바인딩하는 단계를 보여준다.
ServiceBinding이 생성된 이후, 서비스 카탈로그는 서비스 인스턴스와 바인딩하는데 필요한 정보를 요청하는 외부 서비스 브로커를 호출한다.
서비스 브로커는 적절한 서비스 어카운트에 대한 애플리케이션 권한/역할을 활성화한다.
서비스 브로커는 매니지드 서비스 인스턴스에 연결하고 액세스하는데 필요한 정보를 리턴한다. 이는 제공자와 서비스에 특화되어 있으므로 서비스 프로바이더와 매니지드 서비스에 따라 다를 수 있다.
연결 자격 증명 매핑
바인딩 후 마지막 단계는 연결 자격 증명과 서비스 특화 정보를 애플리케이션에 매핑하는 것이다.
이런 정보는 클러스터의 애플리케이션이 액세스하여 매니지드 서비스와 직접 연결하는데 사용할 수 있는 시크릿으로 저장된다.
파드 구성 파일
이 매핑을 수행하는 한 가지 방법은 선언적 파드 구성을 사용하는 것이다.
다음 예시는 서비스 자격 증명을 애플리케이션에 매핑하는 방법을 설명한다. sa-key라는 키는 provider-cloud-key라는 볼륨에 저장되며, 애플리케이션은 이 볼륨을 /var/secrets/provider/key.json에 마운트한다. 환경 변수 PROVIDER_APPLICATION_CREDENTIALS는 마운트된 파일의 값에서 매핑된다.
쿠버네티스 커맨드 라인 도구인 kubectl을 사용하면
쿠버네티스 클러스터에 대해 명령을 실행할 수 있다.
kubectl 을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하고,
로그를 볼 수 있다. kubectl 전체 명령어를 포함한 추가 정보는
kubectl 레퍼런스 문서에서 확인할 수 있다.
kubectl 은 다양한 리눅스 플랫폼, macOS, 그리고 윈도우에 설치할 수 있다.
각각에 대한 설치 가이드는 다음과 같다.
kind 와 마찬가지로, minikube는 쿠버네티스를 로컬에서 실행할 수 있는
도구이다. minikube 는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서
단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을
수행할 수 있다.
도구 설치에 중점을 두고 있다면 공식 사이트에서의
시작하기!
가이드를 따라 해볼 수 있다.
kubectl이 쿠버네티스 클러스터를 찾아 접근하려면,
kube-up.sh를
사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는
kubeconfig 파일이
필요하다.
기본적으로, kubectl 구성은 ~/.kube/config 에 있다.
클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다.
kubectl cluster-info
URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르게 구성된 것이다.
다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다.
The connection to the server <server-name:port> was refused - did you specify the right host or port?
예를 들어, 랩톱에서 로컬로 쿠버네티스 클러스터를 실행하려면, Minikube와 같은 도구를 먼저 설치한 다음 위에서 언급한 명령을 다시 실행해야 한다.
kubectl cluster-info가 URL 응답을 반환하지만 클러스터에 접근할 수 없는 경우, 올바르게 구성되었는지 확인하려면 다음을 사용한다.
kubectl cluster-info dump
선택적 kubectl 구성
셸 자동 완성 활성화
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
경고: bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS의 기본 설치 버전) 버전용이고, v2는 Bash 4.1 이상 버전용이다. kubectl 자동 완성 스크립트는 bash-completion v1과 Bash 3.2 버전에서는 작동하지 않는다. bash-completion v2 와 Bash 4.1 이상 버전 이 필요하다. 따라서, macOS에서 kubectl 자동 완성 기능을 올바르게 사용하려면, Bash 4.1 이상을 설치하고 사용해야 한다(지침). 다음의 내용에서는 Bash 4.1 이상(즉, 모든 Bash 버전 4.1 이상)을 사용한다고 가정한다.
Bash 업그레이드
여기의 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 다음을 실행하여 Bash 버전을 확인할 수 있다.
echo$BASH_VERSION
너무 오래된 버전인 경우, Homebrew를 사용하여 설치/업그레이드할 수 있다.
brew install bash
셸을 다시 로드하고 원하는 버전을 사용 중인지 확인한다.
echo$BASH_VERSION$SHELL
Homebrew는 보통 /usr/local/bin/bash 에 설치한다.
bash-completion 설치
참고: 언급한 바와 같이, 이 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 이는 bash-completion v2를 설치한다는 것을 의미한다(Bash 3.2 및 bash-completion v1의 경우, kubectl 자동 완성이 작동하지 않음).
bash-completion v2가 이미 설치되어 있는지 type_init_completion 으로 확인할 수 있다. 그렇지 않은 경우, Homebrew로 설치할 수 있다.
brew install bash-completion@2
이 명령의 출력에 명시된 바와 같이, ~/.bash_profile 파일에 다음을 추가한다.
kubectl이 쿠버네티스 클러스터를 찾아 접근하려면,
kube-up.sh를
사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는
kubeconfig 파일이
필요하다.
기본적으로, kubectl 구성은 ~/.kube/config 에 있다.
클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다.
kubectl cluster-info
URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르게 구성된 것이다.
다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다.
The connection to the server <server-name:port> was refused - did you specify the right host or port?
예를 들어, 랩톱에서 로컬로 쿠버네티스 클러스터를 실행하려면, Minikube와 같은 도구를 먼저 설치한 다음 위에서 언급한 명령을 다시 실행해야 한다.
kubectl cluster-info가 URL 응답을 반환하지만 클러스터에 접근할 수 없는 경우, 올바르게 구성되었는지 확인하려면 다음을 사용한다.
kubectl cluster-info dump
선택적 kubectl 구성
셸 자동 완성 활성화
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
kubectl이 쿠버네티스 클러스터를 찾아 접근하려면,
kube-up.sh를
사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는
kubeconfig 파일이
필요하다.
기본적으로, kubectl 구성은 ~/.kube/config 에 있다.
클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다.
kubectl cluster-info
URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르게 구성된 것이다.
다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다.
The connection to the server <server-name:port> was refused - did you specify the right host or port?
예를 들어, 랩톱에서 로컬로 쿠버네티스 클러스터를 실행하려면, Minikube와 같은 도구를 먼저 설치한 다음 위에서 언급한 명령을 다시 실행해야 한다.
kubectl cluster-info가 URL 응답을 반환하지만 클러스터에 접근할 수 없는 경우, 올바르게 구성되었는지 확인하려면 다음을 사용한다.
kubectl cluster-info dump
선택적 kubectl 구성
셸 자동 완성 활성화
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
다음은 Zsh에 대한 자동 완성을 설정하는 절차이다.
Zsh용 kubectl 자동 완성 스크립트는 kubectl completion zsh 명령으로 생성할 수 있다. 셸에서 자동 완성 스크립트를 소싱하면 kubectl 자동 완성 기능이 활성화된다.
모든 셸 세션에서 사용하려면, ~/.zshrc 파일에 다음을 추가한다.
source <(kubectl completion zsh)
kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다.
echo'alias k=kubectl' >>~/.zshrc
echo'complete -F __start_kubectl k' >>~/.zshrc
셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다.
complete:13: command not found: compdef 와 같은 오류가 발생하면, ~/.zshrc 파일의 시작 부분에 다음을 추가한다.
kubectl이 쿠버네티스 클러스터를 찾아 접근하려면,
kube-up.sh를
사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는
kubeconfig 파일이
필요하다.
기본적으로, kubectl 구성은 ~/.kube/config 에 있다.
클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다.
kubectl cluster-info
URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르게 구성된 것이다.
다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다.
The connection to the server <server-name:port> was refused - did you specify the right host or port?
예를 들어, 랩톱에서 로컬로 쿠버네티스 클러스터를 실행하려면, Minikube와 같은 도구를 먼저 설치한 다음 위에서 언급한 명령을 다시 실행해야 한다.
kubectl cluster-info가 URL 응답을 반환하지만 클러스터에 접근할 수 없는 경우, 올바르게 구성되었는지 확인하려면 다음을 사용한다.
kubectl cluster-info dump
4.1.4.3 - macOS에서 bash 자동 완성 사용하기
macOS에서 bash 자동 완성을 위한 몇 가지 선택적 구성에 대해 설명한다.
소개
Bash의 kubectl 자동 완성 스크립트는 kubectl completion bash 로 생성할 수 있다. 이 스크립트를 셸에 소싱하면 kubectl 자동 완성이 가능하다.
경고: bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS의 기본 설치 버전) 버전용이고, v2는 Bash 4.1 이상 버전용이다. kubectl 자동 완성 스크립트는 bash-completion v1과 Bash 3.2 버전에서는 작동하지 않는다. bash-completion v2 와 Bash 4.1 이상 버전 이 필요하다. 따라서, macOS에서 kubectl 자동 완성 기능을 올바르게 사용하려면, Bash 4.1 이상을 설치하고 사용해야 한다(지침). 다음의 내용에서는 Bash 4.1 이상(즉, 모든 Bash 버전 4.1 이상)을 사용한다고 가정한다.
Bash 업그레이드
여기의 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 다음을 실행하여 Bash 버전을 확인할 수 있다.
echo$BASH_VERSION
너무 오래된 버전인 경우, Homebrew를 사용하여 설치/업그레이드할 수 있다.
brew install bash
셸을 다시 로드하고 원하는 버전을 사용 중인지 확인한다.
echo$BASH_VERSION$SHELL
Homebrew는 보통 /usr/local/bin/bash 에 설치한다.
bash-completion 설치
참고: 언급한 바와 같이, 이 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 이는 bash-completion v2를 설치한다는 것을 의미한다(Bash 3.2 및 bash-completion v1의 경우, kubectl 자동 완성이 작동하지 않음).
bash-completion v2가 이미 설치되어 있는지 type_init_completion 으로 확인할 수 있다. 그렇지 않은 경우, Homebrew로 설치할 수 있다.
brew install bash-completion@2
이 명령의 출력에 명시된 바와 같이, ~/.bash_profile 파일에 다음을 추가한다.
기본적으로, kubeadm은 클러스터를 실행하는 데 필요한 모든 인증서를 생성한다.
사용자는 자체 인증서를 제공하여 이 동작을 무시할 수 있다.
이렇게 하려면, --cert-dir 플래그 또는 kubeadm ClusterConfiguration 의
certificatesDir 필드에 지정된 디렉터리에 배치해야 한다.
기본적으로 /etc/kubernetes/pki 이다.
kubeadm init 을 실행하기 전에 지정된 인증서와 개인 키(private key) 쌍이 존재하면,
kubeadm은 이를 덮어 쓰지 않는다. 이는 예를 들어, 기존 CA를
/etc/kubernetes/pki/ca.crt 와 /etc/kubernetes/pki/ca.key 에
복사할 수 있고, kubeadm은 이 CA를 사용하여 나머지 인증서에 서명한다는 걸 의미한다.
외부 CA 모드
ca.key 파일이 아닌 ca.crt 파일만 제공할
수도 있다(이는 다른 인증서 쌍이 아닌 루트 CA 파일에만 사용 가능함).
다른 모든 인증서와 kubeconfig 파일이 있으면, kubeadm은 이 조건을
인식하고 "외부 CA" 모드를 활성화한다. kubeadm은 디스크에
CA 키없이 진행한다.
대신, --controllers=csrsigner 사용하여 controller-manager를
독립적으로 실행하고 CA 인증서와 키를 가리킨다.
check-expiration 하위 명령을 사용하여 인증서가 만료되는 시기를 확인할 수 있다.
kubeadm certs check-expiration
출력 결과는 다음과 비슷하다.
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Dec 30, 2020 23:36 UTC 364d no
apiserver Dec 30, 2020 23:36 UTC 364d ca no
apiserver-etcd-client Dec 30, 2020 23:36 UTC 364d etcd-ca no
apiserver-kubelet-client Dec 30, 2020 23:36 UTC 364d ca no
controller-manager.conf Dec 30, 2020 23:36 UTC 364d no
etcd-healthcheck-client Dec 30, 2020 23:36 UTC 364d etcd-ca no
etcd-peer Dec 30, 2020 23:36 UTC 364d etcd-ca no
etcd-server Dec 30, 2020 23:36 UTC 364d etcd-ca no
front-proxy-client Dec 30, 2020 23:36 UTC 364d front-proxy-ca no
scheduler.conf Dec 30, 2020 23:36 UTC 364d no
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Dec 28, 2029 23:36 UTC 9y no
etcd-ca Dec 28, 2029 23:36 UTC 9y no
front-proxy-ca Dec 28, 2029 23:36 UTC 9y no
이 명령은 /etc/kubernetes/pki 폴더의 클라이언트 인증서와 kubeadm이 사용하는 KUBECONFIG 파일(admin.conf, controller-manager.conf 및 scheduler.conf)에 포함된 클라이언트 인증서의 만료/잔여 기간을 표시한다.
또한, kubeadm은 인증서가 외부에서 관리되는지를 사용자에게 알린다. 이 경우 사용자는 수동으로 또는 다른 도구를 사용해서 인증서 갱신 관리를 해야 한다.
경고:kubeadm 은 외부 CA가 서명한 인증서를 관리할 수 없다.
참고: kubeadm은 자동 인증서 갱신을 위해 kubelet을 구성하기 때문에 kubelet.conf 는 위 목록에 포함되어 있지 않다.
경고:
kubeadm 1.17 이전의 버전에서 kubeadm init 으로 작성된 노드에는
kubelet.conf 의 내용을 수동으로 수정해야 하는 버그가 있다. kubeadm init 수행 완료 후, client-certificate-data 및 client-key-data 를 다음과 같이 교체하여,
로테이트된 kubelet 클라이언트 인증서를 가리키도록 kubelet.conf 를 업데이트해야 한다.
이 기능은 가장 간단한 유스케이스를 해결하기 위해 설계되었다.
인증서 갱신에 대해 특별한 요구 사항이 없고 쿠버네티스 버전 업그레이드를 정기적으로(매 1년 이내 업그레이드 수행) 수행하는 경우, kubeadm은 클러스터를 최신 상태로 유지하고 합리적으로 보안을 유지한다.
참고: 보안을 유지하려면 클러스터를 자주 업그레이드하는 것이 가장 좋다.
인증서 갱신에 대해 보다 복잡한 요구 사항이 있는 경우, --certificate-renewal=false 를 kubeadm upgrade apply 또는 kubeadm upgrade node 와 함께 사용하여 기본 동작이 수행되지 않도록 할 수 있다.
경고: kubeadm 1.17 이전 버전에는 kubeadm upgrade node 명령에서
--certificate-renewal 의 기본값이 false 인 버그가
있다. 이 경우 --certificate-renewal=true 를 명시적으로 설정해야 한다.
수동 인증서 갱신
kubeadm certs renew 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.
이 명령은 /etc/kubernetes/pki 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
경고: HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 이 명령을 실행해야 한다.
참고:certs renew 는 기존 인증서를 kubeadm-config 컨피그맵(ConfigMap) 대신 속성(공통 이름, 조직, SAN 등)의 신뢰할 수 있는 소스로 사용한다. 둘 다 동기화 상태를 유지하는 것을 강력히 권장한다.
kubeadm certs renew 는 다음의 옵션을 제공한다.
쿠버네티스 인증서는 일반적으로 1년 후 만료일에 도달한다.
--csr-only 는 실제로 인증서를 갱신하지 않고 인증서 서명 요청을 생성하여 외부 CA로 인증서를 갱신하는 데 사용할 수 있다. 자세한 내용은 다음 단락을 참고한다.
모든 인증서 대신 단일 인증서를 갱신할 수도 있다.
쿠버네티스 인증서 API를 사용하여 인증서 갱신
이 섹션에서는 쿠버네티스 인증서 API를 사용하여 수동 인증서 갱신을 실행하는 방법에 대한 자세한 정보를 제공한다.
주의: 조직의 인증서 인프라를 kubeadm으로 생성된 클러스터에 통합해야 하는 사용자를 위한 고급 주제이다. 기본 kubeadm 구성이 요구 사항을 충족하면 kubeadm이 인증서를 대신 관리하도록 해야 한다.
서명자 설정
쿠버네티스 인증 기관(Certificate Authority)은 기본적으로 작동하지 않는다.
cert-manager와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다.
이 섹션에서는 외부 CA를 사용하여 수동 인증서 갱신을 실행하는 방법에 대한 자세한 정보를 제공한다.
외부 CA와 보다 효과적으로 통합하기 위해 kubeadm은 인증서 서명 요청(CSR)을 생성할 수도 있다.
CSR은 클라이언트의 서명된 인증서에 대한 CA 요청을 나타낸다.
kubeadm 관점에서, 일반적으로 온-디스크(on-disk) CA에 의해 서명되는 모든 인증서는 CSR로 생성될 수 있다. 그러나 CA는 CSR로 생성될 수 없다.
인증서 서명 요청(CSR) 생성
kubeadm certs renew --csr-only 로 인증서 서명 요청을 만들 수 있다.
CSR과 함께 제공되는 개인 키가 모두 출력된다.
--csr-dir 로 사용할 디텍터리를 전달하여 지정된 위치로 CSR을 출력할 수 있다.
--csr-dir 을 지정하지 않으면, 기본 인증서 디렉터리(/etc/kubernetes/pki)가 사용된다.
kubeadm certs renew --csr-only 로 인증서를 갱신할 수 있다.
kubeadm init 과 마찬가지로 출력 디렉터리를 --csr-dir 플래그로 지정할 수 있다.
CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다.
인증서를 발행할 때 올바른 인증서 용도를 지정하는 것은 CA의 책임이다.
# 1.20.x-00에서 x를 최신 패치 버전으로 바꾼다.
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.20.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.20.x-00
# 1.20.x-0에서 x를 최신 패치 버전으로 바꾼다.
yum install -y kubeadm-1.20.x-0 --disableexcludes=kubernetes
다운로드하려는 버전이 잘 받아졌는지 확인한다.
kubeadm version
업그레이드 계획을 확인한다.
kubeadm upgrade plan
이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다.
또한 컴포넌트 구성 버전 상태가 있는 표를 보여준다.
참고: 또한 kubeadm upgrade 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다.
인증서 갱신을 하지 않으려면 --certificate-renewal=false 플래그를 사용할 수 있다.
자세한 내용은 인증서 관리 가이드를 참고한다.
참고:kubeadm upgrade plan 이 수동 업그레이드가 필요한 컴포넌트 구성을 표시하는 경우, 사용자는
--config 커맨드 라인 플래그를 통해 대체 구성이 포함된 구성 파일을 kubeadm upgrade apply 에 제공해야 한다.
그렇게 하지 않으면 kubeadm upgrade apply 가 오류와 함께 종료되고 업그레이드를 수행하지 않는다.
업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다.
# 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
sudo kubeadm upgrade apply v1.20.x
명령이 완료되면 다음을 확인해야 한다.
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.20.x". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
CNI 제공자 플러그인을 수동으로 업그레이드한다.
CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다.
애드온 페이지에서
사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다.
CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다.
다른 컨트롤 플레인 노드의 경우
첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다.
sudo kubeadm upgrade node
아래 명령 대신 위의 명령을 사용한다.
sudo kubeadm upgrade apply
kubeadm upgrade plan 을 호출하고 CNI 공급자 플러그인을 업그레이드할 필요가 없다.
노드 드레인
Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
# <node-to-drain>을 드레인하는 노드의 이름으로 바꾼다.
kubectl drain <node-to-drain> --ignore-daemonsets
# 1.20.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.20.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.20.x-00
# 1.20.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubeadm-1.20.x-0 --disableexcludes=kubernetes
"kubeadm upgrade" 호출
워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다.
sudo kubeadm upgrade node
노드 드레인
스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다.
# <node-to-drain>을 드레이닝하려는 노드 이름으로 바꾼다.
kubectl drain <node-to-drain> --ignore-daemonsets
# <node-to-drain>을 노드의 이름으로 바꾼다.
kubectl uncordon <node-to-drain>
클러스터 상태 확인
모든 노드에서 kubelet을 업그레이드한 후 kubectl이 클러스터에 접근할 수 있는 곳에서 다음의 명령을 실행하여
모든 노드를 다시 사용할 수 있는지 확인한다.
kubectl get nodes
모든 노드에 대해 STATUS 열에 Ready 가 표시되어야 하고, 버전 번호가 업데이트되어 있어야 한다.
장애 상태에서의 복구
예를 들어 kubeadm upgrade 를 실행하는 중에 예기치 못한 종료로 인해 업그레이드가 실패하고 롤백하지 않는다면, kubeadm upgrade 를 다시 실행할 수 있다.
이 명령은 멱등성을 보장하며 결국 실제 상태가 선언한 의도한 상태인지 확인한다.
잘못된 상태에서 복구하기 위해, 클러스터가 실행 중인 버전을 변경하지 않고 kubeadm upgrade apply --force 를 실행할 수도 있다.
업그레이드하는 동안 kubeadm은 /etc/kubernetes/tmp 아래에 다음과 같은 백업 폴더를 작성한다.
kubeadm-backup-etcd-<date>-<time>
kubeadm-backup-manifests-<date>-<time>
kubeadm-backup-etcd 는 컨트롤 플레인 노드에 대한 로컬 etcd 멤버 데이터의 백업을 포함한다.
etcd 업그레이드가 실패하고 자동 롤백이 작동하지 않으면, 이 폴더의 내용을
/var/lib/etcd 에서 수동으로 복원할 수 있다. 외부 etcd를 사용하는 경우 이 백업 폴더는 비어있다.
kubeadm-backup-manifests 는 컨트롤 플레인 노드에 대한 정적 파드 매니페스트 파일의 백업을 포함한다.
업그레이드가 실패하고 자동 롤백이 작동하지 않으면, 이 폴더의 내용을
/etc/kubernetes/manifests 에서 수동으로 복원할 수 있다. 어떤 이유로 특정 컴포넌트의 업그레이드 전
매니페스트 파일과 업그레이드 후 매니페스트 파일 간에 차이가 없는 경우, 백업 파일은 기록되지 않는다.
작동 원리
kubeadm upgrade apply 는 다음을 수행한다.
클러스터가 업그레이드 가능한 상태인지 확인한다.
API 서버에 접근할 수 있다
모든 노드가 Ready 상태에 있다
컨트롤 플레인이 정상적으로 동작한다
버전 차이(skew) 정책을 적용한다.
컨트롤 플레인 이미지가 사용 가능한지 또는 머신으로 가져올 수 있는지 확인한다.
컴포넌트 구성에 버전 업그레이드가 필요한 경우 대체 구성을 생성하거나 사용자가 제공한 것으로 덮어 쓰기한다.
컨트롤 플레인 컴포넌트 또는 롤백 중 하나라도 나타나지 않으면 업그레이드한다.
새로운 kube-dns 와 kube-proxy 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다.
API 서버의 새 인증서와 키 파일을 작성하고 180일 후에 만료될 경우 이전 파일을 백업한다.
kubeadm upgrade node 는 추가 컨트롤 플레인 노드에서 다음을 수행한다.
클러스터에서 kubeadm ClusterConfiguration 을 가져온다.
선택적으로 kube-apiserver 인증서를 백업한다.
컨트롤 플레인 컴포넌트에 대한 정적 파드 매니페스트를 업그레이드한다.
이 노드의 kubelet 구성을 업그레이드한다.
kubeadm upgrade node 는 워커 노드에서 다음을 수행한다.
클러스터에서 kubeadm ClusterConfiguration 을 가져온다.
이 노드의 kubelet 구성을 업그레이드한다.
4.2.1.3 - 윈도우 노드 추가
FEATURE STATE:Kubernetes v1.18 [beta]
쿠버네티스를 사용하여 리눅스와 윈도우 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 윈도우에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 윈도우 노드를 클러스터에 등록하는 방법을 보여준다.
시작하기 전에
쿠버네티스 서버의 버전은 다음과 같거나 더 높아야 함. 버전: 1.17.
버전 확인을 위해서, 다음 커맨드를 실행 kubectl version.
윈도우 컨테이너를 호스팅하는 윈도우 노드를 구성하려면
윈도우 서버 2019 라이선스 이상이 필요하다.
VXLAN/오버레이 네트워킹을 사용하는 경우 KB4489899도 설치되어 있어야 한다.
컨트롤 플레인 호스트에서 kubeadm init 실행할 때 제공된 명령을 사용한다.
이 명령이 더 이상 없거나, 토큰이 만료된 경우, kubeadm token create --print-join-command
(컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다.
컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다.
이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command`
(컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다.
참고:CRI-containerD 를 사용하는 경우 kubeadm 호출에 --cri-socket "npipe:////./pipe/containerd-containerd" 를 추가한다
설치 확인
이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다.
kubectl get nodes -o wide
새 노드가 NotReady 상태인 경우 플란넬 이미지가 여전히 다운로드 중일 수 있다.
kube-system 네임스페이스에서 flannel 파드를 확인하여 이전과 같이 진행 상황을 확인할 수 있다.
kubectl -n kube-system get pods -l app=flannel
flannel 파드가 실행되면, 노드는 Ready 상태가 되고 워크로드를 처리할 수 있어야 한다.
이 페이지는 네임스페이스에 대한 기본 메모리 요청량(request)과 상한(limit)을 구성하는 방법을 보여준다.
기본 메모리 상한이 있는 네임스페이스에서 컨테이너가 생성되고, 컨테이너가
자체 메모리 상한을 지정하지 않으면, 컨테이너에 기본 메모리 상한이 할당된다.
쿠버네티스는 이 문서의 뒷부분에서 설명하는 특정 조건에서 기본 메모리 요청량을 할당한다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
이 페이지는 네임스페이스에 대한 기본 CPU 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다.
쿠버네티스 클러스터는 네임스페이스로 나눌 수 있다. 기본 CPU 상한이 있는 네임스페이스에서
컨테이너가 생성되고, 컨테이너가 자체 CPU 상한을 지정하지 않으면,
컨테이너에 기본 CPU 상한이 할당된다. 쿠버네티스는 이 문서의 뒷부분에서
설명하는 특정 조건에서 기본 CPU 요청량을 할당한다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
이 페이지는 네임스페이스에서 실행되는 컨테이너가 사용하는 메모리의 최솟값과 최댓값을
설정하는 방법을 보여준다. 리밋레인지(LimitRange)
오브젝트에 최소 및 최대 메모리 값을
지정한다. 파드가 리밋레인지에 의해 부과된 제약 조건을 충족하지 않으면,
네임스페이스에서 생성될 수 없다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
컨테이너가 너무 큰 메모리 상한을 지정하므로, 출력 결과에 파드가 생성되지 않은 것으로
표시된다.
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml":
pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container is 1Gi, but limit is 1536Mi.
최소 메모리 요청량을 충족하지 않는 파드 생성 시도
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
100MiB의 메모리 요청량과 800MiB의 메모리 상한을 지정한다.
컨테이너가 너무 작은 메모리 요청량을 지정하므로, 출력 결과에 파드가 생성되지
않은 것으로 표시된다.
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml":
pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container is 500Mi, but request is 100Mi.
메모리 요청량 또는 상한을 지정하지 않은 파드 생성
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
메모리 요청량을 지정하지 않으며, 메모리 상한을 지정하지 않는다.
컨테이너가 자체 메모리 요청량과 상한을 지정하지 않았으므로,
리밋레인지의 메모리의 요청량과 상한 기본값이
제공되었다.
이 시점에서, 컨테이너가 실행 중이거나 실행 중이 아닐 수 있다. 이 태스크의 전제 조건은
노드에 최소 1GiB의 메모리가 있어야 한다는 것이다. 각 노드에
1GiB의 메모리만 있는 경우, 노드에 할당할 수 있는 메모리가 1GiB의 메모리 요청량을 수용하기에 충분하지
않을 수 있다. 메모리가 2GiB인 노드를 사용하는 경우에는, 메모리가
1GiB 요청량을 수용하기에 충분할 것이다.
파드를 삭제한다.
kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example
메모리의 최소 및 최대 제약 조건 적용
리밋레인지에 의해 네임스페이스에 부과된 메모리의 최대 및 최소 제약 조건은
파드를 생성하거나 업데이트할 때만 적용된다. 리밋레인지를 변경해도, 이전에 생성된
파드에는 영향을 미치지 않는다.
메모리의 최소 및 최대 제약 조건에 대한 동기
클러스터 관리자는 파드가 사용할 수 있는 메모리 양에 제한을 둘 수 있다.
예를 들면 다음과 같다.
클러스터의 각 노드에는 2GB의 메모리가 있다. 클러스터의 어떤 노드도 2GB 이상의 요청량을
지원할 수 없으므로, 2GB 이상의 메모리를 요청하는 파드를 수락하지 않으려고 한다.
클러스터는 운영 부서와 개발 부서에서 공유한다.
프로덕션 워크로드가 최대 8GB의 메모리를 소비하도록 하려면,
개발 워크로드를 512MB로 제한해야 한다. 프로덕션 및 개발을 위해
별도의 네임스페이스를 만들고, 각 네임스페이스에 메모리 제약 조건을 적용한다.
이 페이지는 네임스페이스에서 컨테이너와 파드가 사용하는 CPU 리소스의 최솟값과 최댓값을 설정하는
방법을 보여준다. 리밋레인지(LimitRange)
오브젝트에 CPU의 최솟값과 최댓값을
지정한다. 리밋레인지에 의해 부과된 제약 조건을 파드가 충족하지 않으면, 네임스페이스에서
생성될 수 없다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
컨테이너가 너무 큰 CPU 상한을 지정하므로, 출력 결과에 파드가 생성되지 않은 것으로
표시된다.
Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-2.yaml":
pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 800m, but limit is 1500m.
최소 CPU 요청량을 충족하지 않는 파드 생성 시도
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
100 millicpu의 CPU 요청량과 800 millicpu의 CPU 상한을 지정한다.
컨테이너가 너무 작은 CPU 요청량을 지정하므로, 출력 결과에 파드가 생성되지
않은 것으로 표시된다.
Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-3.yaml":
pods "constraints-cpu-demo-3" is forbidden: minimum cpu usage per Container is 200m, but request is 100m.
CPU 요청량 또는 상한을 지정하지 않은 파드 생성
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
CPU 요청량을 지정하지 않으며, CPU 상한을 지정하지 않는다.
kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --output=yaml
출력 결과는 파드의 컨테이너에 대한 CPU 요청량이 800 millicpu이고, CPU 상한이 800 millicpu임을 나타낸다.
컨테이너는 어떻게 이런 값을 얻었을까?
resources:limits:cpu:800mrequests:cpu:800m
컨테이너가 자체 CPU 요청량과 상한을 지정하지 않았으므로, 리밋레인지로부터
CPU 요청량과 상한의 기본값이
주어졌다.
이 시점에서, 컨테이너는 실행 중이거나 실행 중이 아닐 수 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다.
파드를 삭제한다.
kubectl delete pod constraints-cpu-demo-4 --namespace=constraints-cpu-example
CPU의 최소 및 최대 제약 조건의 적용
리밋레인지에 의해 네임스페이스에 부과된 CPU의 최대 및 최소 제약 조건은
파드를 생성하거나 업데이트할 때만 적용된다. 리밋레인지를 변경해도, 이전에 생성된 파드에는
영향을 미치지 않는다.
CPU의 최소 및 최대 제약 조건에 대한 동기
클러스터 관리자는 파드가 사용할 수 있는 CPU 리소스에 제한을 둘 수 있다.
예를 들면 다음과 같다.
클러스터의 각 노드에는 2 CPU가 있다. 클러스터의 어떤 노드도 요청량을 지원할 수 없기 때문에,
2 CPU 이상을 요청하는 파드를 수락하지 않으려고 한다.
클러스터는 프로덕션과 개발 부서에서 공유한다.
프로덕션 워크로드가 최대 3 CPU를 소비하도록 하고 싶지만, 개발 워크로드는 1 CPU로
제한하려고 한다. 프로덕션과 개발을 위해 별도의 네임스페이스를 생성하고, 각 네임스페이스에 CPU 제약 조건을
적용한다.
두 번째 파드는 생성되지 않는다. 출력 결과는 두 번째 파드를 생성하면
메모리 요청량의 총 합계가 메모리 요청량 쿼터를 초과함을 보여준다.
Error from server (Forbidden): error when creating "examples/admin/resource/quota-mem-cpu-pod-2.yaml":
pods "quota-mem-cpu-demo-2" is forbidden: exceeded quota: mem-cpu-demo,
requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests.memory=1Gi
토론
이 연습에서 보았듯이, 리소스쿼터를 사용하여
네임스페이스에서 실행 중인 모든 컨테이너에 대한 메모리 요청량의 총 합계를 제한할 수 있다.
메모리 상한, CPU 요청량 및 CPU 상한의 총 합계를 제한할 수도 있다.
클라이언트 인증서로 인증을 사용하는 경우 easyrsa, openssl 또는 cfssl
을 통해 인증서를 수동으로 생성할 수 있다.
easyrsa
easyrsa 는 클러스터 인증서를 수동으로 생성할 수 있다.
easyrsa3의 패치 버전을 다운로드하여 압축을 풀고, 초기화한다.
curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
tar xzf easy-rsa.tar.gz
cd easy-rsa-master/easyrsa3
./easyrsa init-pki
새로운 인증 기관(CA)을 생성한다. --batch 는 자동 모드를 설정한다.
--req-cn 는 CA의 새 루트 인증서에 대한 일반 이름(Common Name (CN))을 지정한다.
서버 인증서와 키를 생성한다.
--subject-alt-name 인수는 API 서버에 접근이 가능한 IP와 DNS
이름을 설정한다. MASTER_CLUSTER_IP 는 일반적으로 API 서버와
컨트롤러 관리자 컴포넌트에 대해 --service-cluster-ip-range 인수로
지정된 서비스 CIDR의 첫 번째 IP이다. --days 인수는 인증서가 만료되는
일 수를 설정하는데 사용된다.
또한, 아래 샘플은 기본 DNS 이름으로 cluster.local 을
사용한다고 가정한다.
인증서 서명 요청(Certificate Signing Request (CSR))을 생성하기 위한 설정 파일을 생성한다.
파일에 저장하기 전에 꺾쇠 괄호(예: <MASTER_IP>)로
표시된 값을 실제 값으로 대체한다(예: csr.conf).
MASTER_CLUSTER_IP 의 값은 이전 하위 섹션에서
설명한 대로 API 서버의 서비스 클러스터 IP이다.
또한, 아래 샘플에서는 cluster.local 을 기본 DNS 도메인
이름으로 사용하고 있다고 가정한다.
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
API 서버의 키와 인증서를 생성하기 위한 JSON 구성파일을
server-csr.json 예시와 같이 생성한다. 꺾쇠 괄호 안의 값을
사용하려는 실제 값으로 변경한다. MASTER_CLUSTER_IP 는
이전 하위 섹션에서 설명한 API 서버의 클러스터 IP이다.
아래 샘플은 기본 DNS 도메인 이름으로 cluster.local 을
사용한다고 가정한다.
configmap/cilium-config created
serviceaccount/cilium created
serviceaccount/cilium-operator created
clusterrole.rbac.authorization.k8s.io/cilium created
clusterrole.rbac.authorization.k8s.io/cilium-operator created
clusterrolebinding.rbac.authorization.k8s.io/cilium created
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
daemonset.apps/cilium create
deployment.apps/cilium-operator created
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, HTTP)의 보안 정책을
적용하는 방법을 설명한다.
실리움을 실 서비스 용도로 배포하기
실리움을 실 서비스 용도의 배포에 관련한 자세한 방법은
실리움 쿠버네티스 설치 안내를 살펴본다.
이 문서는 자세한 요구사항, 방법과
실제 데몬셋 예시를 포함한다.
실리움 구성요소 이해하기
실리움으로 클러스터를 배포하면 파드가 kube-system 네임스페이스에 추가된다.
파드의 목록을 보려면 다음을 실행한다.
kubectl get pods --namespace=kube-system
다음과 유사한 파드의 목록을 볼 것이다.
NAME READY STATUS RESTARTS AGE
cilium-6rxbd 1/1 Running 0 1m
...
cilium 파드는 클러스터 각 노드에서 실행되며, 리눅스 BPF를 사용해서
해당 노드의 파드에 대한 트래픽 네트워크 폴리시를 적용한다.
다음 내용
클러스터가 동작하면,
실리움으로 쿠버네티스 네트워크 폴리시를 시도하기 위해
네트워크 폴리시 선언하기를 따라 할 수 있다.
재미있게 즐기고, 질문이 있다면
실리움 슬랙 채널을 이용하여 연락한다.
운영 중인 쿠버네티스 클러스터가 필요하다. 클러스터가 없다면, Kops, Bootkube, Kubeadm 등을 이용해서 클러스터를 생성할 수 있다.
큐브 라우터 애드온 설치하기
큐브 라우터 애드온은 갱신된 모든 네트워크 폴리시 및 파드에 대해 쿠버네티스 API 서버를 감시하고, 정책에 따라 트래픽을 허용하거나 차단하도록 iptables 규칙와 ipset을 구성하는 네트워크 폴리시 컨트롤러와 함께 제공된다. 큐브 라우터 애드온을 설치하는 큐브 라우터를 클러스터 인스톨러와 함께 사용하기 안내서를 따라해 봅니다.
다음 내용
큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 네트워크 폴리시 선언하기를 따라 할 수 있다.
4.2.4.4 - 네트워크 폴리시로 로마나(Romana)
이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다.
클러스터는 CoreDNS 애드온을 구동하고 있어야 한다.
CoreDNS로 이관하기
는 kubeadm 을 이용하여 kube-dns 로부터 이관하는 방법을 설명한다.
쿠버네티스 서버의 버전은 다음과 같거나 더 높아야 함. 버전: v1.12.
버전 확인을 위해서, 다음 커맨드를 실행 kubectl version.
소개
DNS는 애드온 관리자 인 클러스터 애드온을
사용하여 자동으로 시작되는 쿠버네티스
내장 서비스이다.
쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우,
CoreDNS 대신 kube-dns 를 계속 사용할 수도 있다.
참고: CoreDNS와 kube-dns 서비스 모두 metadata.name 필드에 kube-dns 로 이름이 지정된다.
이를 통해, 기존의 kube-dns 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. kube-dns 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
Kubelet 은 --cluster-dns=<dns-service-ip> 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다.
DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 --cluster-domain=<default-local-domain> 플래그를
통하여 로컬 도메인을 설정할 수 있다.
DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다.
더 자세한 내용은 서비스 및 파드용 DNS를 참고한다.
만약 파드의 dnsPolicy 가 default 로 지정되어 있는 경우,
파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다.
파드의 DNS 변환도 노드와 동일하게 작동해야 한다.
그 외에는 알려진 이슈를 참고한다.
만약 위와 같은 방식을 원하지 않거나, 파드를 위해 다른 DNS 설정이 필요한 경우,
사용자는 kubelet 의 --resolv-conf 플래그를 사용할 수 있다.
파드가 DNS를 상속받지 못하도록 하기 위해 이 플래그를 ""로 설정한다.
DNS 상속을 위해 /etc/resolv.conf 이외의 파일을 지정할 경우 유효한 파일 경로를 설정한다.
CoreDNS
CoreDNS는 dns 명세를 준수하며 클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다.
CoreDNS 컨피그맵(ConfigMap) 옵션
CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다.
이는 CoreDNS 구성 파일인 Corefile을 관리하여 구성할 수 있다.
클러스터 관리자는 CoreDNS Corefile에 대한 컨피그맵을 수정하여
해당 클러스터에 대한 DNS 서비스 검색 동작을
변경할 수 있다.
health: CoreDNS의 상태(healthy)가 http://localhost:8080/health 에 기록된다. 이 확장 구문에서 lameduck 은 프로세스를 비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다.
ready: 8181 포트의 HTTP 엔드포인트가, 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다.
kubernetes: CoreDNS가 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. 해당 플러그인에 대한 세부 사항은 CoreDNS 웹사이트에서 확인할 수 있다. ttl 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다. 허용되는 최소 TTL은 0초이며, 최대값은 3600초이다. 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다.
pods insecure 옵션은 kube-dns 와의 하위 호환성을 위해 제공된다. pods verified 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만 A 레코드를 반환하게 할 수 있다. pods disabled 옵션은 파드 레코드를 사용하지 않을 경우 사용된다.
prometheus: CoreDNS의 메트릭은 프로메테우스 형식(OpenMetrics 라고도 알려진)의 http://localhost:9153/metrics 에서 사용 가능하다.
forward: 쿠버네티스 클러스터 도메인에 없는 쿼리들은 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다.
Kubeadm 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의
자동 변환을 지원한다.
참고: kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 허용하지만 CoreDNS에서는 이 기능을 지원하지 않는다.
변환 과정에서, 모든 FQDN 네임서버는 CoreDNS 설정에서 생략된다.
kube-dns에 대응되는 CoreDNS 설정
CoreDNS는 kube-dns 이상의 기능을 지원한다.
StubDomains 과 upstreamNameservers 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 forward 플러그인으로 변환된다.
마찬가지로, kube-dns의 Federations 플러그인은 CoreDNS의 federation 플러그인으로 변환된다.
예시
kube-dns에 대한 이 컨피그맵 예제는 federations, stubDomains 및 upstreamNameservers를 지정한다.
구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 kube-up이나 kube-down 스크립트에 쿠버네티스 마스터를 복제할 수 있다.
이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 마스터를 관리하는 방법과 GCE와 함께 사용하기 위해 HA 마스터를 구현하는 방법에 관해 설명한다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
새 HA 호환 클러스터를 생성하려면, kube-up 스크립트에 다음 플래그를 설정해야 한다.
MULTIZONE=true - 서버의 기본 존(zone)과 다른 존에서 마스터 복제본의 kubelet이 제거되지 않도록 한다.
다른 존에서 마스터 복제본을 실행하려는 경우에 권장하고 필요하다.
ENABLE_ETCD_QUORUM_READ=true - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다.
true인 경우, Etcd의 리더 복제본에서 읽는다.
이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다.
선택적으로 첫 번째 마스터 복제본이 생성될 GCE 존을 지정할 수 있다.
다음 플래그를 설정한다.
KUBE_GCE_ZONE=zone - 첫 마스터 복제본이 실행될 존.
다음 샘플 커맨드는 europe-west1-b GCE 존에 HA 호환 클러스터를 구성한다.
다른 존에 마스터 복제본을 배치하도록 한다. 한 존이 실패하는 동안, 해당 존에 있는 마스터도 모두 실패할 것이다.
존 장애를 극복하기 위해 노드를 여러 존에 배치한다
(더 자세한 내용은 멀티 존를 참조한다).
두 개의 마스터 복제본은 사용하지 않는다. 두 개의 복제 클러스터에 대한 합의는 지속적 상태를 변경해야 할 때 두 복제본 모두 실행해야 한다.
결과적으로 두 복제본 모두 필요하고, 어떤 복제본의 장애에도 클러스터가 대부분 장애 상태로 변한다.
따라서 두 개의 복제본 클러스터는 HA 관점에서 단일 복제 클러스터보다 열등하다.
마스터 복제본을 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다.
클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다.
이 작업은 여기 기술한 대로
Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다).
구현 지침
개요
각 마스터 복제본은 다음 모드에서 다음 구성 요소를 실행한다.
Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다.
API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다.
컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다.
애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다.
또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다.
로드 밸런싱
두 번째 마스터 복제본을 시작할 때, 두 개의 복제본을 포함된 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다.
비슷하게 끝에서 두 번째의 마스터 복제본을 제거한 후에는 로드 밸런서가 제거되고
해당 IP 주소는 마지막으로 남은 복제본에 할당된다.
로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다.
마스터 서비스와 Kubelet
쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신,
시스템은 모든 트래픽을 외부 IP 주소로 보낸다.
단일 마스터 클러스터에서 IP 주소는 단일 마스터를 가리킨다.
다중 마스터 클러스터에서 IP 주소는 마스터 앞에 로드밸런서를 가리킨다.
마찬가지로 Kubelet은 외부 IP 주소를 사용하여 마스터와 통신한다.
마스터 인증서
쿠버네티스는 각 복제본의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 마스터 TLS 인증서를 발급한다.
복제본의 임시 공개 IP 주소에 대한 인증서는 없다.
임시 퍼블릭 IP 주소를 통해 복제본에 접근하려면, TLS 검증을 건너뛰어야 한다.
etcd 클러스터화
etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용).
이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다.
API 서버 신원
FEATURE STATE:Kubernetes v1.20 [alpha]
API 서버 식별 기능은
기능 게이트에
의해 제어되며 기본적으로 활성화되지 않는다.
API 서버
시작 시 APIServerIdentity 라는 기능 게이트를 활성화하여 API 서버 신원을 활성화할 수 있다.
kube-apiserver \
--feature-gates=APIServerIdentity=true\
# …다른 플래그는 평소와 같다.
부트스트랩 중에 각 kube-apiserver는 고유한 ID를 자신에게 할당한다. ID는
kube-apiserver-{UUID} 형식이다. 각 kube-apiserver는
kube-system네임스페이스에
임대를 생성한다.
임대 이름은 kube-apiserver의 고유 ID이다. 임대에는
k8s.io/component=kube-apiserver 라는 레이블이 있다. 각 kube-apiserver는
IdentityLeaseRenewIntervalSeconds (기본값은 10초)마다 임대를 새로 갱신한다. 각
kube-apiserver는 IdentityLeaseDurationSeconds (기본값은 3600초)마다
모든 kube-apiserver 식별 ID 임대를 확인하고,
IdentityLeaseDurationSeconds 이상 갱신되지 않은 임대를 삭제한다.
IdentityLeaseRenewIntervalSeconds 및 IdentityLeaseDurationSeconds는
kube-apiserver 플래그 identity-lease-renew-interval-seconds
및 identity-lease-duration-seconds로 구성된다.
이 기능을 활성화하는 것은 HA API 서버 조정과 관련된 기능을
사용하기 위한 전제조건이다(예: StorageVersionAPI 기능 게이트).
설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존
스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정
스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를
동적으로 프로비저닝 하기 위해 사용된다.
더 자세한 내용은 퍼시스턴트볼륨클레임 문서를
보자.
미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지
않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할
수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
하여 스토리지의 동적 프로비저닝을 방지할 수 있다.
기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동 중인
애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자
및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자.
기본 스토리지클래스 변경하기
사용자의 클러스터에 있는 스토리지클래스 목록을 조회한다.
kubectl get storageclass
결과는 아래와 유사하다.
NAME PROVISIONER AGE
standard (default) kubernetes.io/gce-pd 1d
gold kubernetes.io/gce-pd 1d
기본 스토리지클래스는 (default) 로 표시되어 있다.
기본 스토리지클래스를 기본값이 아닌 것으로 표시한다.
기본 스토리지클래스에는
storageclass.kubernetes.io/is-default-class 의 값이 true 로 설정되어 있다.
다른 값이거나 어노테이션이 없을 경우 false 로 처리된다.
스토리지클래스를 기본값이 아닌 것으로 표시하려면, 그 값을 false 로 변경해야 한다.
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
여기서 standard 는 사용자가 선택한 스토리지클래스의 이름이다.
스토리지클래스를 기본값으로 표시한다.
이전 과정과 유사하게, 어노테이션을 추가/설정해야 한다.
storageclass.kubernetes.io/is-default-class=true.
이 문서는 사용자가 쿠버네티스 네트워크폴리시 API를 사용하여 파드(Pod)가 서로 통신하는 방법을 제어하는 네트워크 폴리시를 선언하는데 도움을 준다.
주의:
이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
nginx 디플로이먼트(Deployment)를 생성하고 서비스(Service)를 통해 노출하기
쿠버네티스 네트워크 폴리시가 어떻게 동작하는지 확인하기 위해서, nginx 디플로이먼트를 생성한다.
kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
nginx 라는 이름의 서비스를 통해 디플로이먼트를 노출한다.
kubectl expose deployment nginx --port=80
service/nginx exposed
위 명령어들은 nginx 파드에 대한 디플로이먼트를 생성하고, nginx 라는 이름의 서비스를 통해 디플로이먼트를 노출한다. nginx 파드와 디플로이먼트는 default 네임스페이스(namespace)에 존재한다.
kubectl get svc,pod
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes 10.100.0.1 <none> 443/TCP 46m
service/nginx 10.100.0.16 <none> 80/TCP 33s
NAME READY STATUS RESTARTS AGE
pod/nginx-701339712-e0qfq 1/1 Running 0 35s
다른 파드에서 접근하여 서비스 테스트하기
사용자는 다른 파드에서 새 nginx 서비스에 접근할 수 있어야 한다. default 네임스페이스에 있는 다른 파드에서 nginx 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다.
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
사용자 쉘에서, 다음의 명령을 실행한다.
wget --spider --timeout=1 nginx
Connecting to nginx (10.100.0.16:80)
remote file exists
nginx 서비스에 대해 접근 제한하기
access: true 레이블을 가지고 있는 파드만 nginx 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다.
참고: 네트워크폴리시는 정책이 적용되는 파드의 그룹을 선택하는 podSelector 를 포함한다. 사용자는 이 정책이 app=nginx 레이블을 갖는 파드를 선택하는 것을 볼 수 있다. 레이블은 nginx 디플로이먼트에 있는 파드에 자동으로 추가된다. 빈 podSelector 는 네임스페이스의 모든 파드를 선택한다.
서비스에 정책 할당하기
kubectl을 사용하여 위 nginx-policy.yaml 파일로부터 네트워크폴리시를 생성한다.
이제, 애플리케이션 개발자는 특정 개수의 동글을 요청하는 파드를
만들 수 있다. 컨테이너에 확장 리소스 할당하기를
참고한다.
토론
확장 리소스는 메모리 및 CPU 리소스와 비슷하다. 예를 들어,
노드에서 실행 중인 모든 컴포넌트가 공유할 특정 양의 메모리와 CPU가
노드에 있는 것처럼, 노드에서 실행 중인 모든 컴포넌트가
특정 동글을 공유할 수 있다. 또한 애플리케이션 개발자가
특정 양의 메모리와 CPU를 요청하는 파드를 생성할 수 있는 것처럼, 특정
동글을 요청하는 파드를 생성할 수 있다.
확장 리소스는 쿠버네티스에게 불투명하다. 쿠버네티스는 그것들이
무엇인지 전혀 모른다. 쿠버네티스는 노드에 특정 개수의 노드만
있다는 것을 알고 있다. 확장 리소스는 정수로 알려야
한다. 예를 들어, 노드는 4.5개의 동글이 아닌, 4개의 동글을 알릴 수 있다.
스토리지 예제
노드에 800GiB의 특별한 종류의 디스크 스토리지가 있다고 가정한다.
example.com/special-storage와 같은 특별한 스토리지의 이름을 생성할 수 있다.
그런 다음 특정 크기, 100GiB의 청크로 알릴 수 있다. 이 경우,
노드에는 example.com/special-storage 유형의 8가지 리소스가 있다고
알린다.
Capacity:...example.com/special-storage:8
이 특별한 스토리지에 대한 임의 요청을 허용하려면,
1바이트 크기의 청크로 특별한 스토리지를 알릴 수 있다. 이 경우, example.com/special-storage 유형의
800Gi 리소스를 알린다.
Capacity:...example.com/special-storage:800Gi
그런 다음 컨테이너는 최대 800Gi의 임의 바이트 수의 특별한 스토리지를 요청할 수 있다.
쿠버네티스 버전 1.10 이상에서, kube-dns 를 사용하는 클러스터를 업그레이드하기 위하여
kubeadm 을 사용할 때 CoreDNS로 전환할 수도 있다. 이 경우, kubeadm 은
kube-dns 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의
설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다.
만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 CoreDNS 값을 true 로 설정해야 한다.
예를 들어, v1.11.0 로 업그레이드 하는 경우는 다음과 같다.
다음과 같이 인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시
사용을 피할 수 있다.
grep/cut 방식을 사용한다.
# .KUBECONFIG에 여러 콘텍스트가 있을 수 있으므로, 가능한 모든 클러스터를 확인한다.
kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'# 위의 출력에서 상호 작용하려는 클러스터의 이름을 선택한다.exportCLUSTER_NAME="some_server_name"# 클러스터 이름을 참조하는 API 서버를 가리킨다.APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")# 토큰 값을 얻는다TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)# TOKEN으로 API 탐색
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
위의 예는 --insecure 플래그를 사용한다. 이로 인해 MITM 공격이
발생할 수 있다. kubectl이 클러스터에 접근하면 저장된 루트 인증서와
클라이언트 인증서를 사용하여 서버에 접근한다. (~/.kube 디렉터리에
설치된다.) 클러스터 인증서는 일반적으로 자체 서명되므로,
http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한 구성이
필요할 수 있다.
일부 클러스터에서, API 서버는 인증이 필요하지 않다.
로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은
없다. 쿠버네티스 API에 대한 접근 제어은
클러스터 관리자로서 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후
고 가용성 지원과 충돌할 수 있다.
Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 kubeconfig 파일을
사용할 수 있다. 이 예제를 참고한다.
fromkubernetesimport client, config
config.load_kube_config()
v1=client.CoreV1Api()
print("Listing pods with their IPs:")
ret = v1.list_pod_for_all_namespaces(watch=False)
for i in ret.items:
print("%s\t%s\t%s"% (i.status.pod_ip, i.metadata.namespace, i.metadata.name))
Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 kubeconfig 파일을
사용할 수 있다. 이 예제를 참고한다.
packageio.kubernetes.client.examples;importio.kubernetes.client.ApiClient;importio.kubernetes.client.ApiException;importio.kubernetes.client.Configuration;importio.kubernetes.client.apis.CoreV1Api;importio.kubernetes.client.models.V1Pod;importio.kubernetes.client.models.V1PodList;importio.kubernetes.client.util.ClientBuilder;importio.kubernetes.client.util.KubeConfig;importjava.io.FileReader;importjava.io.IOException;/**
* 쿠버네티스 클러스터 외부의 애플리케이션에서 Java API를 사용하는 방법에 대한 간단한 예
*
* <p>이것을 실행하는 가장 쉬운 방법: mvn exec:java
* -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample"
*
*/publicclassKubeConfigFileClientExample{publicstaticvoidmain(String[] args)throws IOException, ApiException {// KubeConfig의 파일 경로
String kubeConfigPath ="~/.kube/config";// 파일시스템에서 클러스터 외부 구성인 kubeconfig 로드
ApiClient client =
ClientBuilder.kubeconfig(KubeConfig.loadKubeConfig(new FileReader(kubeConfigPath))).build();// 전역 디폴트 api-client를 위에서 정의한 클러스터 내 클라이언트로 설정
Configuration.setDefaultApiClient(client);// CoreV1Api는 전역 구성에서 디폴트 api-client를 로드
CoreV1Api api =new CoreV1Api();// CoreV1Api 클라이언트를 호출한다
V1PodList list = api.listPodForAllNamespaces(null,null,null,null,null,null,null,null,null);
System.out.println("Listing all pods: ");for(V1Pod item : list.getItems()){
System.out.println(item.getMetadata().getName());}}}
파드를 실행한 다음, kubectl exec를 사용하여 셸에 연결한다.
해당 셸에서 다른 노드, 파드 및 서비스에 연결한다.
일부 클러스터는 클러스터의 노드로 ssh를 통해 접근하는 것을 허용한다. 거기에서 클러스터 서비스에
접근할 수 있다. 이것은 비표준 방법이며, 일부 클러스터에서는 작동하지만 다른 클러스터에서는
작동하지 않는다. 브라우저 및 기타 도구가 설치되거나 설치되지 않을 수 있다. 클러스터 DNS가 작동하지 않을 수도 있다.
빌트인 서비스 검색
일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다.
kubectl cluster-info 커맨드로 이 서비스의 리스트를 볼 수 있다.
kubectl cluster-info
출력은 다음과 비슷하다.
Kubernetes master is running at https://104.197.5.247
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
각 서비스에 접근하기 위한 프록시-작업 URL이 표시된다.
예를 들어, 이 클러스터에는 https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/ 로
접근할 수 있는 (Elasticsearch를 사용한) 클러스터 수준 로깅이 활성화되어 있다. 적합한 자격 증명이 전달되는 경우나 kubectl proxy를 통해 도달할 수 있다. 예를 들어 다음의 URL에서 확인할 수 있다.
http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/.
위에서 언급한 것처럼, kubectl cluster-info 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 서비스의 프록시 URL에 추가하면 된다.
http://kubernetes_master_address/api/v1/namespaces/namespace_name/services/[https:]service_name[:port_name]/proxy
포트에 대한 이름을 지정하지 않은 경우, URL에 port_name 을 지정할 필요가 없다.
예제
Elasticsearch 서비스 엔드포인트 _search?q=user:kimchy 에 접근하려면, 다음을 사용한다.
퍼시스턴트볼륨은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한
다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 퍼시스턴트볼륨의 경우
기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 PersistentVolumeClaim 을 삭제하면,
동적으로 프로비저닝 된 볼륨이 자동적으로 삭제됨을 의미한다.
볼륨에 중요한 데이터가 포함된 경우, 이러한 자동 삭제는 부적절 할 수 있다.
이 경우에는, "Retain" 정책을 사용하는 것이 더 적합하다.
"Retain" 정책에서, 사용자가 퍼시스턴트볼륨클레임을 삭제할 경우 해당하는
퍼시스턴트볼륨은 삭제되지 않는다.
대신, Released 단계로 이동되어, 모든 데이터를 수동으로 복구할 수 있다.
kubectl top pod memory-demo --namespace=mem-example
출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다.
이는 파드의 100 MiB 요청 보다 많으나
파드의 200 MiB 상한보다는 적다.
NAME CPU(cores) MEMORY(bytes)
memory-demo <something> 162856960
파드 삭제:
kubectl delete pod memory-demo --namespace=mem-example
컨테이너의 메모리 상한을 초과
노드 내 메모리가 충분하다면 컨테이너는 지정한 요청량보다 많은 메모리를 사용 할 수 있다. 그러나
컨테이너는 지정한 메모리 상한보다 많은 메모리를 사용할 수 없다. 만약 컨테이너가 지정한 메모리 상한보다
많은 메모리를 할당하면 해당 컨테이너는 종료 대상 후보가 된다. 만약 컨테이너가 지속적으로
지정된 상한보다 많은 메모리를 사용한다면, 해당 컨테이너는 종료된다. 만약 종료된 컨테이너가
재실행 가능하다면 다른 런타임 실패와 마찬가지로 kubelet에 의해 재실행된다.
이 예제에서는 상한보다 많은 메모리를 할당하려는 파드를 생성한다.
이 것은 50 MiB 메모리 요청량과 100 MiB 메모리 상한을 갖는
하나의 컨테이너를 갖는 파드의 구성 파일이다.
이 예제에서 컨테이너는 재실행 가능하여 kubelet에 의해 재실행된다.
컨테이너가 종료되었다 재실행되는 것을 보기 위해 다음 명령을 몇 번 반복한다.
kubectl get pod memory-demo-2 --namespace=mem-example
출력은 컨테이너의 종료, 재실행, 재종료, 재실행 등을 보여준다.
kubectl get pod memory-demo-2 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 37s
kubectl get pod memory-demo-2 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-2 1/1 Running 2 40s
파드 내역에 대한 상세 정보 보기:
kubectl describe pod memory-demo-2 --namespace=mem-example
컨테이너가 반복적으로 시작하고 실패 하는 출력을 보여준다.
... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
... Warning BackOff Back-off restarting failed container
클러스터 노드에 대한 자세한 정보 보기:
kubectl describe nodes
출력에는 컨테이너가 메모리 부족으로 종료된 기록이 포함된다.
Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child
파드 삭제:
kubectl delete pod memory-demo-2 --namespace=mem-example
노드에 비해 너무 큰 메모리 요청량의 지정
메모리 요청량과 상한은 컨테이너와 관련있지만, 파드가 가지는
메모리 요청량과 상한으로 이해하면 유용하다. 파드의 메모리 요청량은
파드 내 모든 컨테이너의 메모리 요청량의 합이다. 마찬가지로
파드의 메모리 상한은 파드 내 모든 컨테이너의 메모리 상한의 합이다.
파드는 요청량을 기반하여 스케줄링된다. 노드에 파드의 메모리 요청량을 충족하기에 충분한 메모리가 있는
경우에만 파드가 노드에서 스케줄링된다.
이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다.
다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는
컨테이너를 갖는
파드의 구성 파일이다.
kubectl get pod memory-demo-3 --namespace=mem-example
파드 상태가 PENDING 상태임이 출력된다. 즉 파드는 어떤 노드에서도 실행되도록 스케줄 되지 않고 PENDING가 계속 지속된다.
kubectl get pod memory-demo-3 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-3 0/1 Pending 0 25s
이벤트를 포함한 파드 상세 정보 보기:
kubectl describe pod memory-demo-3 --namespace=mem-example
출력은 노드 내 메모리가 부족하여 파드가 스케줄링될 수 없음을 보여준다.
Events:
... Reason Message
------ -------
... FailedScheduling No nodes are available that match all of the following predicates:: Insufficient memory (3).
메모리 단위
메모리 리소스는 byte 단위로 측정된다. 다음 접미사 중 하나로 정수 또는 고정 소수점으로
메모리를 표시할 수 있다. E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki.
예를 들어 다음은 거의 유사한 값을 나타낸다.
128974848, 129e6, 129M , 123Mi
파드 삭제:
kubectl delete pod memory-demo-3 --namespace=mem-example
메모리 상한을 지정하지 않으면
컨테이너에 메모리 상한을 지정하지 않으면 다음 중 하나가 적용된다.
컨테이너가 사용할 수 있는 메모리 상한은 없다. 컨테이너가
실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 없는 컨테이너가 종료될 가능성이 크다.
기본 메모리 상한을 갖는 네임스페이스 내에서 실행중인 컨테이너는
자동으로 기본 메모리 상한이 할당된다. 클러스터 관리자들은
LimitRange를
사용해 메모리 상한의 기본 값을 지정 가능하다.
메모리 요청량과 상한 동기부여
클러스터에서 실행되는 컨테이너에 메모리 요청량과 상한을 구성하여
클러스터 내 노드들의 메모리 리소스를 효율적으로 사용할 수 있게 할 수 있다.
파드의 메모리 요청량을 적게 유지하여 파드가 높은 확률로 스케줄링 될 수 있도록 한다.
메모리 상한이 메모리 요청량보다 크면 다음 두 가지가 수행된다.
가용한 메모리가 있는 경우 파드가 이를 사용할 수 있는 버스트(burst) 활동을 할 수 있다.
참고: 컨테이너가 자신의 메모리 상한을 지정하지만, 메모리 요청량을 지정하지 않는 경우,
쿠버네티스는 상한과 일치하는 메모리 요청량을 자동으로 할당한다. 이와 유사하게, 만약 컨테이너가 자신의
CPU 상한을 지정하지만, CPU 요청량을 지정하지 않은 경우, 쿠버네티스는 상한과 일치하는 CPU 요청량을 자동으로
할당한다.
파드를 삭제한다.
kubectl delete pod qos-demo --namespace=qos-example
Burstable QoS 클래스가 할당되는 파드 생성
다음의 경우 파드에 Burstable QoS 클래스가 부여된다.
파드가 Guaranteed QoS 클래스 기준을 만족하지 않는다.
파드 내에서 최소한 하나의 컨테이너가 메모리 또는 CPU 요청량을 가진다.
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
200MiB의 메모리 상한과 100MiB의 메모리 요청량을 가진다.
컨테이너 파일 시스템은 컨테이너가 살아있는 동안만 존재한다. 따라서
컨테이너가 종료되고 재시작할 때, 파일 시스템 변경사항이 손실된다. 컨테이너와
독립적이며 보다 일관된 스토리지를 위해 사용자는 볼륨을
사용할 수 있다. 이것은 레디스(Redis)와 같은 키-값 저장소나
데이터베이스와 같은 스테이트풀 애플리케이션에 매우 중요하다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
쿠버네티스는 emptyDir 이 제공하는 로컬 디스크 스토리지뿐만 아니라,
중요한 데이터에 선호하는 GCE의 PD, EC2의 EBS를 포함해서
네트워크 연결 스토리지(NAS) 솔루션을 지원하며,
노드의 디바이스 마운트, 언마운트와 같은 세부사항을 처리한다.
자세한 내용은 볼륨을 참고한다.
클러스터 관리자로서, 물리적 스토리지와 연결되는 퍼시스턴트볼륨을
생성한다. 볼륨을 특정 파드와 연결하지 않는다.
그 다음 개발자 / 클러스터 사용자의 역할로서, 적합한
퍼시스턴트볼륨에 자동으로 바인딩되는 퍼시스턴트볼륨클레임을
생성한다.
스토리지에 대해 위의 퍼시스턴트볼륨클레임을 사용하는 파드를 생성한다.
시작하기 전에
사용자는 노드가 단 하나만 있는 쿠버네티스 클러스터가 필요하고,
kubectl
커맨드라인 툴이 사용자의 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 만약 사용자가
아직 단일 노드 클러스터를 가지고 있지 않다면, Minikube를
사용하여 클러스터 하나를 생성할 수 있다.
사용자 클러스터의 단일 노드에 연결되는 셸을 연다. 셸을 여는 방법은
클러스터 설정에 따라 달라진다. 예를 들어 Minikube를 사용하는 경우,
minikube ssh 명령어를 입력하여 노드로 연결되는 셸을 열 수 있다.
해당 노드의 셸에서 /mnt/data 디렉터리를 생성한다.
# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여# "sudo"를 사용한다고 가정한다
sudo mkdir /mnt/data
/mnt/data 디렉터리에서 index.html 파일을 생성한다.
# 이번에도 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여# "sudo"를 사용한다고 가정한다
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"
참고: 사용자 노드에서 sudo 이외의 슈퍼유저 접근 툴을 사용하는 경우,
sudo 를 해당 툴의 이름으로 바꾸면, 동일하게 작업을 수행할 수 있다.
index.html 파일이 존재하는지 테스트한다.
cat /mnt/data/index.html
결과는 다음과 같다.
Hello from Kubernetes storage
이제 사용자 노드에서 셸을 종료해도 된다.
퍼시스턴트볼륨 생성하기
이 예제에서, 사용자는 hostPath 퍼시스턴트볼륨을 생성한다. 쿠버네티스는 단일 노드에서의
개발과 테스트를 위해 hostPath를 지원한다. hostPath 퍼시스턴트볼륨은
네트워크로 연결된 스토리지를 모방하기 위해, 노드의 파일이나 디렉터리를 사용한다.
운영 클러스터에서, 사용자가 hostPath를 사용하지는 않는다. 대신, 클러스터 관리자는
Google Compute Engine 영구 디스크, NFS 공유 또는 Amazone Elastic
Block Store 볼륨과 같은 네트워크 자원을 프로비저닝한다. 클러스터 관리자는
스토리지클래스(StorageClasses)를
사용하여
동적 프로비저닝을 설정할 수도 있다.
설정 파일에 클러스터 노드의 /mnt/data 에 볼륨이 있다고
지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가
읽기-쓰기 모드로 볼륨을 마운트할 수 있는 ReadWriteOnce 접근 모드를
지정한다. 여기서는
퍼시스턴트볼륨클레임의 스토리지클래스 이름을
manual 로 정의하며, 퍼시스턴트볼륨클레임의 요청을
이 퍼시스턴트볼륨에 바인딩하는데 사용한다.
결과는 퍼시스턴트볼륨의 STATUS 가 Available 임을 보여준다. 이는
아직 퍼시스턴트볼륨클레임이 바인딩되지 않았다는 것을 의미한다.
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
task-pv-volume 10Gi RWO Retain Available manual 4s
퍼시스턴트볼륨클레임 생성하기
다음 단계는 퍼시스턴트볼륨클레임을 생성하는 단계이다. 파드는 퍼시스턴트볼륨클레임을
사용하여 물리적인 스토리지를 요청한다. 이 예제에서, 사용자는 적어도
하나 이상의 노드에 대해 읽기-쓰기 접근을 지원하며 최소 3 기가바이트의 볼륨을 요청하는
퍼시스턴트볼륨클레임을 생성한다.
만약 클러스터의 노드에 대한 셸이 열려져 있지 않은 경우,
이전과 동일한 방식으로 새로운 셸을 연다.
사용자 노드의 셸에서, 생성한 파일과 디렉터리를 제거한다.
# 사용자 노드에서 슈퍼유저로 명령을 수행하기 위하여# "sudo"를 사용한다고 가정한다
sudo rm /mnt/data/index.html
sudo rmdir /mnt/data
이제 사용자 노드에서 셸을 종료해도 된다.
접근 제어
그룹 ID(GID)로 설정된 스토리지는 동일한 GID를 사용하는 파드에서만 쓰기
작업을 허용한다. GID가 일치하지 않거나 누락되었을 경우 권한
거부 오류가 발생한다. 사용자와의 조정 필요성을 줄이기 위하여 관리자는
퍼시스턴트 볼륨에 GID로 어노테이션을 달 수 있다. 그 뒤에, 퍼시스턴트볼륨을
사용하는 모든 파드에 대하여 GID가 자동으로 추가된다.
파드가 GID 어노테이션이 있는 퍼시스턴트볼륨을 사용하면, 어노테이션으로
달린 GID가 파드의 보안 컨텍스트에 지정된 GID와 동일한 방식으로
파드의 모든 컨테이너에 적용된다. 파드의 명세 혹은 퍼시스턴트볼륨의
어노테이션으로부터 생성된 모든 GID는, 각 컨테이너에서 실행되는 첫 번째
프로세스에 적용된다.
참고: 파드가 퍼시스턴트볼륨을 사용할 때, 퍼시스턴트볼륨과 연관된
GID는 파드 리소스 자체에는 존재하지 않는다.
만약 error: no objects passed to create 메세지가 출력될 경우, base64로 인코딩된 문자열이 유효하지 않음을 의미한다.
또한 Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ... 메세지가 출력될 경우,
base64로 인코딩된 문자열이 정상적으로 디코딩되었으나, .docker/config.json 파일로 파싱되지 못한 것을 의미한다.
출력 결과는 nginx가 초기화 컨테이너에 의해 저장된 웹 페이지를 제공하고 있음을 보여준다.
<html><head></head><body><header>
<title>http://info.cern.ch</title>
</header>
<h1>http://info.cern.ch - home of the first website</h1>
...
<li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
...
스태틱 파드 는 API 서버
없이 특정 노드에 있는 kubelet 데몬에 의해
직접 관리된다.
컨트롤 플레인에 의해 관리되는 파드(예를 들어 디플로이먼트(Deployment))와는 달리,
kubelet이 각각의 스태틱 파드를 감시한다.
(만약 실패할 경우 다시 구동한다.)
Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버에서 미러 파드(mirror pod)를
생성하려고 자동으로 시도한다.
즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만,
API 서버에서 제어될 수는 없다.
파드 이름에는 노드 호스트 이름 앞에 하이픈을 붙여 접미사로 추가된다.
참고: 만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여
모든 노드에서 파드를 구동하고 있다면,
스태틱 파드를 사용하는 대신 데몬셋(DaemonSet)
을 사용하는 것이 바람직하다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다.
kubelet 구성 파일의 staticPodPath: <the directory> 필드를 사용하자.
명시한 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
kubelet이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.
예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다.
스태틱 파드를 실행할 노드를 선택한다. 이 예제에서는 my-model 이다.
ssh my-node1
/etc/kubelet.d 와 같은 디렉터리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 /etc/kubelet.d/static-web.yaml 에 배치한다.
# kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
mkdir /etc/kubelet.d/
cat <<EOF >/etc/kubelet.d/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
EOF
노드에서 kubelet 실행 시에 --pod-manifest-path=/etc/kubelet.d/ 와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 /etc/kubernetes/kubelet 파일을 다음과 같이 수정한다.
혹은 kubelet 구성 파일에
staticPodPath: <the directory> 필드를 추가한다.
kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다.
# kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
systemctl restart kubelet
웹이 호스팅 하는 스태틱 파드 매니페스트
Kubelet은 --manifest-url=<URL> 의 인수로 지정된 파일을 주기적으로 다운로드하여
해당 파일을 파드의 정의가 포함된 JSON/YAML 파일로 해석한다.
파일시스템이 호스팅 하는 매니페스트 의 작동 방식과
유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에
변경된 부분이 있을 경우, kubelet 은 이를 적용한다.
이 방법을 사용하기 위하여 다음을 수행한다.
kubelet 에게 파일의 URL을 전달하기 위하여 YAML 파일을 생성하고 이를 웹 서버에 저장한다.
# kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
systemctl restart kubelet
스태틱 파드 행동 관찰하기
Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다.
스태틱 파드를 정의하고, kubelet을 재시작했으므로, 새로운 스태틱
파드가 이미 실행 중이어야 한다.
(노드에서) 구동되고 있는 (스태틱 파드를 포함한) 컨테이너들을 볼 수 있다.
# kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
docker ps
결과는 다음과 유사하다.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
API 서버에서 미러 파드를 볼 수 있다.
kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 2m
참고: Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다.
파드시큐리티폴리시(PodSecurityPolicy) 에 대해 보기.
스태틱 파드에 있는 레이블 은
미러 파드로 전파된다. 셀렉터 등을
통하여 이러한 레이블을 사용할 수 있다.
만약 API 서버로부터 미러 파드를 지우기 위하여 kubectl 을 사용하려 해도,
kubelet 은 스태틱 파드를 지우지 않는다.
kubectl delete pod static-web-my-node1
pod "static-web-my-node1" deleted
파드가 여전히 구동 중인 것을 볼 수 있다.
kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 12s
kubelet이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로
중지할 수 있다.
일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는
것을 볼 수 있다.
# kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.
docker stop f6d05272b57e # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다.
sleep 20
docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
스태틱 파드의 동적 추가 및 제거
실행 중인 kubelet 은 주기적으로, 설정된 디렉터리(예제에서는 /etc/kubelet.d)에서 변경 사항을 스캔하고, 이 디렉터리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다.
# 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다.# kubelet이 동작하고 있는 노드에서 이 명령을 수행한다.#
mv /etc/kubelet.d/static-web.yaml /tmp
sleep 20
docker ps
# 구동 중인 nginx 컨테이너가 없는 것을 확인한다.
mv /tmp/static-web.yaml /etc/kubelet.d/
sleep 20
docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
4.4 - 쿠버네티스 오브젝트 관리
쿠버네티스 API와 상호 작용하기 위한 선언적이고 명령적인 패러다임
4.4.1 - 구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리
쿠버네티스 오브젝트는 여러 개의 오브젝트 구성 파일을
디렉터리에 저장하고 필요에 따라 kubectl apply를
사용하여 재귀적으로 오브젝트를 생성하고 업데이트함으로써 생성, 업데이트 및 삭제할 수 있다.
이 방식은 변경사항을 되돌려 오브젝트 구성 파일에 병합하지 않고
활성 오브젝트에 가해진 기록을 유지한다. kubectl diff는 또한
apply가 어떠한 변경사항을 이루어질지에 대한 프리뷰를 제공한다.
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
출력은 kubectl.kubernetes.io/last-applied-configuration 어노테이션이
활성 구성에 기록된 것을 보여주며, 그것은 구성 파일과 일치한다.
kind:Deploymentmetadata:annotations:# ...# This is the json representation of simple_deployment.yaml# It was written by kubectl apply when the object was createdkubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:# ...minReadySeconds:5selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.14.2# ...name:nginxports:- containerPort:80# ...# ...# ...# ...
오브젝트 업데이트 방법
또한 오브젝트가 기존에 존재하더라도 디렉터리 내 정의된 모든 오브젝트를 업데이트하기 위해 kubectl apply를
사용할 수 있다. 이러한 접근방식은 다음을 수행할 수 있게 해준다.
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
출력은 kubectl.kubernetes.io/last-applied-configuration 어노테이션이
활성 구성에 기록된 것을 보여주며, 그것은 구성 파일과 일치한다.
kind:Deploymentmetadata:annotations:# ...# This is the json representation of simple_deployment.yaml# It was written by kubectl apply when the object was createdkubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:# ...minReadySeconds:5selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.14.2# ...name:nginxports:- containerPort:80# ...# ...# ...# ...
kubectl scale을 사용하여 활성 구성 내 replicas 필드를 직접 업데이트한다.
이는 kubectl apply를 사용하지 않는다.
출력은 replicas 필드가 2로 설정된 것을 보여주며, last-applied-configuration
어노테이션은 replicas 필드를 포함하지 않는다.
apiVersion:apps/v1kind:Deploymentmetadata:annotations:# ...# note that the annotation does not contain replicas# because it was not updated through applykubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:replicas:2# written by scale# ...minReadySeconds:5selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.14.2# ...name:nginxports:- containerPort:80# ...
nginx:1.14.2에서 nginx:1.16.1로 이미지를 변경하기 위해 simple_deployment.yaml
구성 파일을 업데이트 하고, minReadySeconds 필드를 삭제한다.
kubectl get -f https://k8s.io/examples/application/update_deployment.yaml -o yaml
출력은 활성 구성에 다음의 변경사항을 보여준다.
replicas 필드는 kubectl scale에 의해 설정된 값 2를 유지한다. 이는 구성 파일에서 생략되었기 때문에 가능하다.
image 필드는 nginx:1.14.2에서 nginx:1.16.1로 업데이트되었다.
last-applied-configuration 어노테이션은 새로운 이미지로 업데이트되었다.
minReadySeconds 필드는 지워졌다.
last-applied-configuration 어노테이션은 더 이상 minReadySeconds 필드를 포함하지 않는다.
apiVersion:apps/v1kind:Deploymentmetadata:annotations:# ...# The annotation contains the updated image to nginx 1.11.9,# but does not contain the updated replicas to 2kubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:replicas:2# Set by `kubectl scale`. Ignored by `kubectl apply`.# minReadySeconds cleared by `kubectl apply`# ...selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.16.1# Set by `kubectl apply`# ...name:nginxports:- containerPort:80# ...# ...# ...# ...
경고: 명령형 오브젝트 구성 커맨드 create와 replace와 함께 kubectl apply를
혼합하는 것은 지원하지 않는다. 이는 kubectl apply가 업데이트 사항을 계산하는데 사용하는
kubectl.kubernetes.io/last-applied-configuration을 create와 replace가
유지하지 하지 않기 때문이다.
오브젝트 삭제 방법
kubectl apply에 의해 관리되는 오브젝트를 삭제하는데 2가지 접근 방법이 있다.
권장 방법: kubectl delete -f <파일명>
명령형 커맨드를 사용하여 오브젝트를 수동으로 삭제하는 것이 권장되는 방식인데,
무엇이 삭제되는지에 대해 더 명확하게 나타내므로 사용자가 의도하지 않게
무언가를 삭제할 가능성이 작아지기 때문이다.
kubectl delete -f <파일명>
대안: kubectl apply -f <디렉터리/> --prune -l your=레이블
무엇을 하는지 파악하는 경우에만 이를 사용한다.
경고:kubectl apply --prune은 알파 상태이며, 후속 릴리스에서는
하위 호환되지 않는 변경 사항이 도입될 수 있다.
경고: 이 명령을 사용할 때는 의도하지 않게 오브젝트를 삭제하지 않도록
주의해야만 한다.
kubectl delete에 대한 대안으로, 디렉터리로부터 구성 파일이 삭제된 후에 삭제될 오브젝트를 식별하기 위해 kubectl apply를 사용할 수 있다.
--prune을 사용하여 적용하면 일련의 레이블의 집합과 일치하는
모든 오브젝트에 대해API 서버에 쿼리하고, 반환된 활성 오브젝트
구성을 오브젝트 구성 파일에 일치시키려고 시도한다.
오브젝트가 쿼리에 일치하고, 해당 디렉터리 내 구성 파일이 없고
last-applied-configuration어노테이션이 있는 경우,
삭제된다.
kubectl apply -f <디렉터리/> --prune -l <레이블>
경고: prune을 사용하여 적용하는 것은 오브젝트 구성 파일을
포함하는 루트 디렉터리에 대해서만 실행해야 한다.
하위 디렉터리에 대해 실행하게 되면,
-l <레이블>로 지정된 레이블 셀렉터에 의해 반환되고 하위 디렉터리에 나타나지 않는 경우,
오브젝트가 의도하지 않게 삭제될 수 있다.
오브젝트 확인 방법
활성 오브젝트의 구성을 확인하기 위해 -o yaml과 함께 kubectl get을 사용할 수 있다.
kubectl get -f <파일명|url> -o yaml
어떻게 apply가 차이를 계산하고 변경을 병합하는가
주의:patch 는 전체 오브젝트 대신 오브젝트의 특정 필드 범위의 오퍼레이션을 업데이트한다.
이는 먼저 오브젝트를 읽지 않고도 오브젝트의 특정 필드 집합만을
업데이트할 수 있도록 해준다.
kubectl apply가 하나의 오브젝트에 대한 활성 구성을 업데이트할 때,
API 서버에 패치 요청을 보냄으로써 그것을 수행한다.
그 패치는 활성 오브젝트 구성의 특정 필드에 대한 범위의
업데이트로 한정한다. kubectl apply 커맨드는
구성 파일, 활성 구성, 그리고 활성 구성에 저장된
last-applied-configuration어노테이션을 사용하여 이 패치 요청을 계산한다.
패치 계산 병합
kubectl apply 명령은
kubectl.kubernetes.io/last-applied-configuration 어노테이션에 구성 파일의 내용을 기록한다.
이것은 구성 파일로부터 제거되었고 활성 구성으로부터 지워질 필요가 있는
필드를 확인하는 데 사용된다. 다음은 어떤 필드가 삭제 또는 설정돼야 하는지
계산하기 위해 사용되는 단계이다.
삭제할 필드를 계산한다. 이것은 last-applied-configuration 내 존재하고 구성 파일로부터 유실된 필드이다.
추가 또는 설정되어야 할 필드를 계산한다. 이것은 활성 구성과 불일치하는 값을 가지는 구성 파일 내 존재하는 필드이다.
apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.16.1# update the imageports:- containerPort:80
또한, 이것은 동일한 디플로이먼트 오브젝트에 대한 활성 구성이라고 가정한다.
apiVersion:apps/v1kind:Deploymentmetadata:annotations:# ...# note that the annotation does not contain replicas# because it was not updated through applykubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:replicas:2# written by scale# ...minReadySeconds:5selector:matchLabels:# ...app:nginxtemplate:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.14.2# ...name:nginxports:- containerPort:80# ...
다음은 kubectl apply에 의해 수행될 병합 계산이다.
last-applied-configuration으로부터 값을 읽어
구성 파일의 값과 비교하여 삭제할 필드를
계산한다.
last-applied-configuration에 보이는 것과는 무관하게
로컬의 오브젝트 구성 파일 내 null이라고 명시적으로 설정된 필드를 지운다.
이 예시에서, minReadySeconds은
last-applied-configuration 어노테이션 내 나타나지만, 구성 파일 내에는 보여지지 않는다.
조치: 활성 구성으로부터 minReadySeconds을 지운다.
구성 파일로부터 값을 읽어 활성 구성 내 값과
비교하여 설정할 필드를 계산한다. 이 예시에서,
구성 파일 내 image 값은 활성 구성 내 값과 불일치한다.
조치: 활성 구성 내 image 값을 설정한다.
구성 파일의 값과 일치시키기 위해 last-applied-configuration
어노테이션을 설정한다.
1, 2, 3으로부터의 결과를 API 서버에 단일 패치 요청으로 병합한다.
다음은 병합의 결과인 활성 구성이다.
apiVersion:apps/v1kind:Deploymentmetadata:annotations:# ...# The annotation contains the updated image to nginx 1.11.9,# but does not contain the updated replicas to 2kubectl.kubernetes.io/last-applied-configuration:| {"apiVersion":"apps/v1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
"ports":[{"containerPort":80}]}]}}}}# ...spec:selector:matchLabels:# ...app:nginxreplicas:2# Set by `kubectl scale`. Ignored by `kubectl apply`.# minReadySeconds cleared by `kubectl apply`# ...template:metadata:# ...labels:app:nginxspec:containers:- image:nginx:1.16.1# Set by `kubectl apply`# ...name:nginxports:- containerPort:80# ...# ...# ...# ...
어떻게 상이한 필드 타입이 병합되는가
구성 파일 내 특정 필드가 필드의 타입에 따라
어떻게 활성 구성과 함께 병합되는가.
여러 가지 필드 타입이 있다.
기본(primitives): 문자열, 숫자 또는 불리언 타입의 필드.
예를 들어, image와 replicas는 기본 필드다. 조치: 교체.
맵, 또한 오브젝트 라 칭함: 맵 타입 또는 서브필드를 포함하는 복합 타입의 필드. 예를 들어, 레이블,
어노테이션,스펙 및 메타데이터는 모두 맵이다. 조치: 구성요소 또는 서브필드 병합.
리스트: 기본타입 또는 맵이 될 수 있는 아이템의 리스트를 포함하는 필드.
예를 들어, 컨테이너, 포트, 그리고 args는 리스트다. 조치: 다양함.
kubectl apply가 맵 또는 리스트 필드를 업데이트하는 경우,
일반적으로 전체 필드를 교체하는 대신, 개별 부 구성요소를 업데이트한다,
예를 들어, 디플로이먼트에 대한 spec을 병합할 경우, 전체 spec이
교체되지 않는다. 대신 replicas와 같은 spec의 서브필드가
비교되고 병합된다.
기본 필드에 대한 변경사항 병합하기
기본 필드는 교체되거나 지워진다.
참고:- 는 값이 사용되지 않기 때문에 "해당 없음"으로 사용된다.
Field in object configuration file
Field in live object configuration
Field in last-applied-configuration
Action
Yes
Yes
-
구성 파일 값 활성으로 설정.
Yes
No
-
활성을 로컬 구성으로 설정.
No
-
Yes
활성 구성으로부터 지움.
No
-
No
아무것도 안함. 활성값 유지.
맵 필드에 변경사항 병합하기
맵을 요청하는 필드는 서브필드의 각각 또는 맵의 구성요소를 비교함으로써 병합된다.
참고:- 는 값이 사용되지 않기 때문에 "해당 없음"으로 사용된다.
Key in object configuration file
Key in live object configuration
Field in last-applied-configuration
Action
Yes
Yes
-
서브필드 값 비교.
Yes
No
-
활성을 로컬 구성으로 설정.
No
-
Yes
활성 구성으로부터 삭제.
No
-
No
아무것도 안함. 활성값 유지.
타입 리스트의 필드에 대한 변경사항 병합하기
리스트에 대한 변경사항을 병합하는 것은 세 가지 전략 중 하나를 사용한다.
구성요소가 모두 기본형인 경우 리스트를 교체한다.
복합 구성요소의 리스트에서 개별 구성요소를 병합한다.
기초 구성요소의 리스트를 병합한다.
전략에 대한 선택은 필드별로 이루어진다.
구성요소가 모두 기본형인 경우 리스트 교체
기초 필드와 동일한 리스트로 취급한다. 전체 리스트를 교체 또는 삭제한다.
이것은 순서를 유지한다.
예시: 파드 내 컨테이너의 args 필드를 업데이트하기 위해 kubectl apply를 사용한다.
이것은 활성 구성 내 args의 값을 구성 파일 내 값으로 설정한다.
활성 구성에 추가했던 이전의 모든 args구성요소들은 유실된다.
구성 파일 내 정의한 args 구성요소의 순서는
활성 구성 내 유지된다.
# last-applied-configuration valueargs:["a","b"]# configuration file valueargs:["a","c"]# live configurationargs:["a","b","d"]# result after mergeargs:["a","c"]
설명: 병합은 새로운 리스트 값으로 구성 파일 값을 사용했다.
복합 구성요소 리스트에 대한 개별 구성요소 병합
리스트를 맵으로 취급하고 각 구성요소의 특정 필드를 키로 취급한다.
개별 구성요소를 추가, 삭제, 또는 업데이트 한다. 이것은 순서를 보존하지 않는다.
이 병합 전략은 각 필드에 patchMergeKey라 칭하는 특별한 태그를 사용한다.
patchMergeKey는 쿠버네티스 소스 코드:
types.go
의 각 필드에 대해 정의한다. 맵 리스트를 병합할 때, 주어진 구성요소에 대한 patchMergeKey로
지정한 필드는 해당 구성요소에 대한 맵키와 같이 사용된다.
예시:kubectl apply를 사용하여 PodSpec에 대한 containers필드를 업데이트한다. 이렇게 하면 각 구성요소가
name별로 키로 되어 있는 맵인 것처럼 리스트를 병합한다.
# last-applied-configuration valuecontainers:- name:nginximage:nginx:1.10- name: nginx-helper-a # key:nginx-helper-a; will be deleted in resultimage:helper:1.3- name: nginx-helper-b # key:nginx-helper-b; will be retainedimage:helper:1.3# configuration file valuecontainers:- name:nginximage:nginx:1.10- name:nginx-helper-bimage:helper:1.3- name: nginx-helper-c # key:nginx-helper-c; will be added in resultimage:helper:1.3# live configurationcontainers:- name:nginximage:nginx:1.10- name:nginx-helper-aimage:helper:1.3- name:nginx-helper-bimage:helper:1.3args:["run"]# Field will be retained- name: nginx-helper-d # key:nginx-helper-d; will be retainedimage:helper:1.3# result after mergecontainers:- name:nginximage:nginx:1.10# Element nginx-helper-a was deleted- name:nginx-helper-bimage:helper:1.3args:["run"]# Field was retained- name:nginx-helper-c# Element was addedimage:helper:1.3- name:nginx-helper-d# Element was ignoredimage:helper:1.3
설명:
구성 파일에 "nginx-helper-a"라는 이름을 가진 컨테이너가 나타나지 않았기 때문에
"nginx-helper-a"라는 컨테이너는 삭제되었다.
"nginx-helper-b"라는 컨테이너는 활성 구성에 args에 대한 변경사항을 유지했다. kubectl apply는 필드 값이 다름에도 불구하고(구성 파일에 args가 없음) 활성 구성에 "nginx-helper-b"가 구성 파일과 동일한
"nginx-helper-b"임을 식별할 수 있었다. 이것은
patchMergeKey 필드 값(이름)이 둘 다 같았기 때문이다..
"nginx-helper-c"라는 이름의 컨테이너가 활성 구성에 나타나지
않았지만, 구성 파일에 그 이름을 가진 컨테이너가 나타났기 때문에
추가되었다.
last-applied-configuration에 그 이름을 가진 구성요소가 없었기 때문에
"nginx-helper-d"라는 이름의 컨테이너는 유지되었다.
기초 구성요소 리스트 병합
쿠버네티스 1.5로부터 기초 구성요소 병합하기는 지원되지 않는다.
참고: 주어진 필드에 대해 위 전략 중 어떤 것을 선택할지에 대해서는
types.go의 patchStrategy 태그에 의해 제어된다.
타입 필드에 대해 patchStrategy가 지정되지 않으면,
리스트는 대체된다.
기본 필드값
오브젝트가 생성될 때 값이 지정되지 않는 경우, API 서버는 활성 구성 내
특정 필드를 기본값으로 설정한다.
kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml
출력은 API 서버가 활성 구성 내 여러 필드를 기본값으로 설정한 것을 보여준다.
이 필드들은 구성 파일에 지정되지 않았다.
apiVersion:apps/v1kind:Deployment# ...spec:selector:matchLabels:app:nginxminReadySeconds:5replicas:1# defaulted by apiserverstrategy:rollingUpdate:# defaulted by apiserver - derived from strategy.typemaxSurge:1maxUnavailable:1type:RollingUpdate# defaulted by apiservertemplate:metadata:creationTimestamp:nulllabels:app:nginxspec:containers:- image:nginx:1.14.2imagePullPolicy:IfNotPresent# defaulted by apiservername:nginxports:- containerPort:80protocol:TCP# defaulted by apiserverresources:{}# defaulted by apiserverterminationMessagePath:/dev/termination-log# defaulted by apiserverdnsPolicy:ClusterFirst# defaulted by apiserverrestartPolicy:Always# defaulted by apiserversecurityContext:{}# defaulted by apiserverterminationGracePeriodSeconds:30# defaulted by apiserver# ...
패치 요청에서, 패치 요청의 부분으로서 명시적으로 지워지지 않은 경우
기본 처리된 필드는 다시 기본으로 설정되지 않는다.
이것은 다른 필드에 대한 값에 따라 기본 처리된 필드에 대해
예상하지 못한 동작을 유발할 수 있다. 다른 필드가 나중에 변경되면,
그로부터 기본 처리된 것이 명시적으로 지워지지 않은 한
업데이트되지 않을 것이다.
이러한 사유로, 의도한 값이 서버의 기본값과 일치하더라도,
서버에 의해 기본 처리된 특정 필드는 구성 파일 내
명시적으로 정의할 것을 권고한다. 이렇게 하면
서버에 의해 다시 기본 처리되지 않게 될 충돌하는 값을 보다 쉽게
인식할 수 있도록 해준다.
Example:
# last-applied-configurationspec:template:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.14.2ports:- containerPort:80# configuration filespec:strategy:type:Recreate# updated valuetemplate:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.14.2ports:- containerPort:80# live configurationspec:strategy:type:RollingUpdate# defaulted valuerollingUpdate:# defaulted value derived from typemaxSurge :1maxUnavailable:1template:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.14.2ports:- containerPort:80# result after merge - ERROR!spec:strategy:type: Recreate # updated value:incompatible with rollingUpdaterollingUpdate: # defaulted value:incompatible with "type: Recreate"maxSurge :1maxUnavailable:1template:metadata:labels:app:nginxspec:containers:- name:nginximage:nginx:1.14.2ports:- containerPort:80
설명:
사용자가 strategy.type을 정의하지 않고 디플로이먼트를 생성한다.
서버는 strategy.type을 RollingUpdate로 기본 설정하고
strategy.rollingUpdate값을 기본 값으로 처리한다.
사용자가 strategy.type를 Recreate로 변경한다.
서버에서 해당 값이 삭제될 거라 예상하지만 strategy.rollingUpdate값은 기본값으로 남아 있다. strategy.rollingUpdate값이 처음에 구성 파일에서 지정되었다면,
이것을 삭제해야 한다는 것이 더 분명했을 것이다.
strategy.rollingUpdate가 지워지지 않았기 때문에 적용은 실패한다.
strategy.rollingupdate 필드는 Recreate의 strategy.type으로 정의될 수 없다.
권고: 이들 필드는 오브젝트 구성 파일 내 명시적으로 정의돼야 한다.
디플로이먼트, 스테이트풀셋, 잡, 데몬셋, 레플리카셋 및 레플리케이션컨트롤러와 같은
워크로드에 대한 셀렉터와 파드템플릿 레이블
디플로이먼트 롤아웃 전략
서버 기본 필드 또는 다른 작성자에 의해 설정된 필드 지우는 방법
구성 파일 내 나타나지 않는 필드는 그 값을
null로 설정하고 나서 구성 파일을 적용함으로써 지워질 수 있다.
서버가 기본 값을 할당했던 필드에 대해서, 이는 다시 기본 값을
할당하도록 한다.
구성 파일과 직접 명령형 작성자 간의 필드 소유권을 변경시키는 방법
개별 오브젝트 필드를 변경시키는 데 사용해야 하는 유일한 방법은 다음과 같다.
kubectl apply를 사용한다.
구성 파일을 수정하지 않고 활성 구성을 직접 작성한다.
예를 들어, kubectl scale을 사용한다.
직접 명령형 작성자에서 구성 파일로 소유자 변경하기
구성 파일에 필드를 추가한다. 해당 필드의 경우
kubectl apply를 거치지 않는 활성 구성에 대해 직접 업데이트를 적용하지 않는다.
구성 파일에서 직접 명령형 작성자로 소유자 변경하기
쿠버네티스 1.5로부터 구성 파일에서 명령형 작성자로 소유권을 변경하는데
수동 단계 필요하다.
구성 파일에서 필드를 제거한다.
활성 오브젝트 상의 kubectl.kubernetes.io/last-applied-configuration 어노테이션에서 필드를 제거한다.
관리 방법 변경하기
쿠버네티스 오브젝트는 한 번에 오직 하나의 방법을 사용하여 관리돼야 한다.
하나의 방법에서 다른 방법으로 전환하는 것은 가능하나, 수동 프로세스이다.
참고: 선언형 관리와 함께 명령형 삭제를 사용하는 것은 괜찮다.
명령형 커맨드 관리에서 오브젝트 구성으로 이전하기
명령형 커맨드 관리에서 오브젝트 구성으로 이전하는 것은
여러 수동 단계를 포함한다.
활성 오브젝트를 로컬 구성 파일로 내보낸다.
kubectl get <종류>/<이름> -o yaml > <종류>_<이름>.yaml
구성 파일에서 수동으로 status 필드를 제거한다.
참고:kubectl apply 구성 파일에 존재한다고 하더라도 상태 필드가 업데이트되지 않기 때문에,
이 단계는 선택적이다.
Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다. 이는 애플리케이션 구성 파일을 관리하기 위해 다음 기능들을 가진다.
다른 소스에서 리소스 생성
리소스에 대한 교차 편집 필드 설정
리소스 집합을 구성하고 사용자 정의
리소스 생성
컨피그 맵과 시크릿은 파드와 같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. 컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 .properties 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다.
Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 secretGenerator와 configMapGenerator를 가지고 있다.
configMapGenerator
파일에서 컨피그 맵을 생성하려면 configMapGenerator 내의 files 리스트에 항목을 추가한다. 다음은 하나의 .properties 파일에서 데이터 항목으로 컨피그 맵을 생성하는 예제이다.
# application.properties 파일을 생성
cat <<EOF >application.properties
FOO=Bar
EOF
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-1
files:
- application.properties
EOF
생성된 컨피그 맵과 시크릿은 콘텐츠 해시 접미사가 추가된다. 이는 콘텐츠가 변경될 때 새로운 컨피그 맵 이나 시크릿이 생성되는 것을 보장한다. 접미사를 추가하는 동작을 비활성화하는 방법으로 generatorOptions를 사용할 수 있다. 그밖에, 생성된 컨피그 맵과 시크릿에 교차 편집 옵션들을 지정해주는 것도 가능하다.
프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서
관리하는 것은 일반적이다.
Kustomize는 서로 다른 파일들로 리소스를 구성하고 패치나 다른 사용자 정의를 이들에 적용하는 것을 제공한다.
구성
Kustomize는 서로 다른 리소스들의 구성을 지원한다. kustomization.yaml 파일 내 resources 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. resources 리스트 내에 리소스의 구성 파일의 경로를 설정한다.
다음 예제는 디플로이먼트와 서비스로 구성된 NGINX 애플리케이션이다.
# deployment.yaml 파일 생성
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
EOF# service.yaml 파일 생성
cat <<EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-nginx
labels:
run: my-nginx
spec:
ports:
- port: 80
protocol: TCP
selector:
run: my-nginx
EOF# 이들을 구성하는 kustomization.yaml 생성
cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
- service.yaml
EOF
kubectl kustomize ./의 리소스에는 디플로이먼트와 서비스 오브젝트가 모두 포함되어 있다.
사용자 정의
패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는
patchesStrategicMerge와 patchesJson6902를 통해 서로 다른 패치 메커니즘을 지원한다. patchesStrategicMerge는 파일 경로들의 리스트이다. 각각의 파일은 전략적 병합 패치로 분석될 수 있어야 한다. 패치 내부의 네임은 반드시 이미 읽혀진 리소스 네임과 일치해야 한다. 한 가지 일을 하는 작은 패치가 권장된다. 예를 들기 위해 디플로이먼트 레플리카 숫자를 증가시키는 하나의 패치와 메모리 상한을 설정하는 다른 패치를 생성한다.
모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해,
Kustomize는 patchesJson6902를 통한 JSON 패치 적용을 제공한다.
Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이
kustomization.yaml 내에 명시될 필요가 있다. 예를 들면, patchesJson6902를 통해
디플로이먼트 오브젝트의 레플리카 개수를 증가시킬 수 있다.
패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는
기능도 제공한다. 예를 들어 kustomization.yaml의 images 필드에 신규 이미지를 지정하여 컨테이너에서 사용되는 이미지를 변경할 수 있다.
가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어,
디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자.
kustomization.yaml 파일에 namePrefix 또는 nameSuffix가 추가되면 서비스 네임이 변경될 수 있다.
커맨드 인수 내에 서비스 네임을 하드 코딩하는 것을 권장하지 않는다. 이 용도에서 Kustomize는 vars를 통해 containers에 서비스 네임을 삽입할 수 있다.
Kustomize는 base 와 overlay 의 개념을 가지고 있다. base 는 kustomization.yaml 과 함께 사용되는 디렉터리다. 이는
사용자 정의와 관련된 리소스들의 집합을 포함한다. kustomization.yaml의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가
될 수 있다. overlay 는 kustomization.yaml이 있는 디렉터리로
다른 kustomization 디렉터리들을 bases로 참조한다. base 는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다.
한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며,
이들의 위에 사용자 정의도 가질 수 있다.
kubectl 툴은 가장 일반적인 오브젝트 타입을 생성하는데 동사 형태 기반의 커맨드를
지원한다. 쿠버네티스 오브젝트 타입에 익숙하지 않은 사용자가 인지할 수 있도록 커맨드
이름이 지어졌다.
run: 컨테이너를 실행할 새로운 파드를 생성한다.
expose: 파드에 걸쳐 트래픽을 로드 밸런스하도록 새로운 서비스 오브젝트를 생성한다.
autoscale: 디플로이먼트와 같이, 하나의 컨트롤러에 대해 자동으로 수평적 스케일이 이루어 지도록 새로운 Autoscaler 오브젝트를 생성한다.
또한 kubectl 툴은 오브젝트 타입에 의해 구동되는 생성 커맨드를 지원한다.
이러한 커맨드는 더 많은 오브젝트 타입을 지원해주며 그 의도하는 바에 대해
보다 명확하게 해주지만, 사용자가 생성하고자 하는 오브젝트 타입에 대해
알 수 있도록 해야 한다.
create <오브젝트 타입> [<서브 타입>] <인스턴스명>
일부 오브젝트 타입은 create 커맨드 내 정의할 수 있는 서브 타입을 가진다.
예를 들어, 서비스 오브젝트는 ClusterIP, LoadBalancer 및 NodePort 등을
포함하는 여러 서브 타입을 가진다, 다음은 NodePort 서브 타입을 통해 서비스를
생성하는 예제이다.
kubectl create service nodeport <사용자 서비스 명칭>
이전 예제에서, create service nodeport 커맨드는
create service 커맨드의 서브 커맨드라고 칭한다.
-h 플래그를 사용하여 서브 커맨드에 의해 지원되는 인수 및 플래그를
찾아 볼 수 있다.
kubectl create service nodeport -h
오브젝트 업데이트 방법
kubectl 커맨드는 일반적인 몇몇의 업데이트 작업을 위해 동사 형태 기반의 커맨드를 지원한다.
이 커맨드는 쿠버네티스 오브젝트에 익숙하지 않은 사용자가 설정되어야
하는 특정 필드를 모르는 상태에서도 업데이트를 수행할 수 있도록
이름 지어졌다.
scale: 컨트롤러의 레플리카 수를 업데이트 함으로써 파드를 추가 또는 제거하는 컨트롤러를 수평적으로 스케일한다.
annotate: 오브젝트로부터 어노테이션을 추가 또는 제거한다.
label: 오브젝트에서 레이블을 추가 또는 제거한다.
kubectl 커맨드는 또한 오브젝트 측면에서 구동되는 업데이트 커맨드를 지원한다.
이 측면의 설정은 다른 오브젝트 타입에 대한 다른 필드를 설정 할 수도 있다.
set<field>: 오브젝트의 측면을 설정한다.
참고: 쿠버네티스 1.5 버전에서는 모든 동사 형태 기반의 커맨드가 관련된 측면 중심의 커맨드를 가지는 것은 아니다.
kubectl 툴은 활성 오브젝트를 직접 업데이트하기 위해 추가적인 방법을 지원하지만,
쿠버네티스 오브젝트 스키마에 대한 추가적인 이해를 요구한다.
edit: 편집기에서 구성을 열어 활성 오브젝트에 대한 원래 그대로의 구성을 바로 편집한다.
patch: 패치 문자열를 사용하여 활성 오브젝트를 바로 편집한다.
패치 문자열에 대한 보다 자세한 정보를 보려면
API 규정에서 패치 섹션을 참고한다.
오브젝트 삭제 방법
클러스터에서 오브젝트를 삭제하기 위해 delete 커맨드을 사용할 수 있다.
delete <타입>/<이름>
참고: 명령형 커맨드와 명령형 오브젝트 구성 모두 kubectl delete를 사용할 수
있다. 차이점은 커맨드에 전해지는 인수에 있다. 명령형 커맨드로
kubectl delete을 사용하기 위해, 삭제할 오브젝트를 인수로 전한다.
다음은 nginx라는 디플로이먼트 오브젝트를 전하는 예제이다.
kubectl delete deployment/nginx
오브젝트 확인 방법
오브젝트에 대한 정보를 출력하는 몇 가지 커맨드가 있다.
get: 일치하는 오브젝트에 대한 기본 정보를 출력한다. 옵션 리스트를 확인하기 위해 get -h를 사용한다.
describe: 일치하는 오브젝트에 대해 수집한 상세한 정보를 출력한다.
logs: 파드에서 실행 중인 컨테이너에 대한 stdout과 stderr를 출력한다.
생성 전 오브젝트 수정을 위해 set 커맨드 사용하기
create 커맨드에 사용할 수 있는 플래그가 없는 몇 가지 오브젝트
필드가 있다. 이러한 경우, 오브젝트 생성 전에 필드에 대한 값을
정의하기 위해 set과 create을 조합해서 사용할 수 있다.
이는 set 커맨드에 create 커맨드의 출력을 파이프 함으로써 수행할 수 있다.
다음은 관련 예제이다.
구성파일로부터 오브젝트를 생성하기 위해 kubectl create -f를 사용할 수 있다.
보다 상세한 정보는 쿠버네티스 API 참조를
참조한다.
kubectl create -f <파일명|url>
오브젝트 업데이트 방법
경고:replace 커맨드로 오브젝트를 업데이트 하게되면,
구성파일에 정의되지 않은 스펙의 모든 부분이 삭제된다. 이는
externalIPs필드가 구성파일로부터 독립적으로 관리되는
LoadBalancer타입의 서비스와 같이, 클러스터 의해 부분적으로
관리되는 스펙의 오브젝트와 함께 사용되어서는 안된다.
독립적으로 관리되는 필드는 replace로 삭제되는 것을 방지하기 위해
구성파일에 복사되어져야만 한다.
구성파일에 따라 활성 오브젝트를 업데이트하기 위해 kubectl replace -f
를 사용할 수 있다.
kubectl replace -f <파일명|url>
오브젝트 삭제 방법
구성파일에 정의한 오브젝트를 삭제하기 위해 kubectl delete -f를
사용할 수 있다.
kubectl delete -f <파일명|url>
참고:
구성 파일이 metadata 섹션에서 name 필드 대신 generateName
필드를 지정한 경우, kubectl delete -f <filename|url> 을 사용하여
오브젝트를 삭제할 수 없다.
오브젝트를 삭제하려면 다른 플래그를 사용해야 한다. 예를 들면, 다음과 같다.
구성파일에 정의한 오브젝트에 관한 정보 확인을 위해 kubectl get -f
명령을 사용할 수 있다.
kubectl get -f <파일명|url> -o yaml
-o yaml 플래그는 전체 오브젝트 구성이 출력되도록 정의한다. 옵션의 리스트를 확인하기
위해서는 kubectl get -h를 사용한다.
제약사항
create, replace, 그리고 delete 명령은 각 오브젝트의 구성이
그 구성파일 내에 완전하게 정의되고 기록되어질 경우 잘 동작한다.
그러나 활성 오브젝트가 업데이트 되고, 구성파일 안에 병합되지 않으면,
업데이트 내용은 다음번 replace가 실행될 때 삭제될 것이다.
이는 HorizontalPodAutoscaler와 같은 컨트롤러가
활성 오브젝트를 직접적으로 업데이트하도록 할 경우 발생한다.
여기 예시가 있다.
구성파일로부터 오브젝트를 생성할 경우
또 다른 소스가 일부 필드를 변경함으로써 오브젝트가 업데이트 되는 경우
구성파일로부터 오브젝트를 대체할 경우. 스텝 2에서의
다른 소스에 의해 이루어진 변경은 유실된다.
동일 오브젝트에 대해 여러 명의 작성자들로부터의 지원이 필요한 경우, 오브젝트를 관리하기 위해
kubectl apply를 사용할 수 있다.
구성 저장 없이 URL로부터 오브젝트 생성과 편집하기
구성파일에 대한 URL을 가진다고 가정해보자.
kubectl create --edit을 사용하여 오브젝트가 생성되기 전에
구성을 변경할 수 있다. 이는 독자가 수정할 수 있는 구성파일을
가르키는 튜토리얼과 작업에 특히 유용하다.
kubectl create -f <url> --edit
명령형 커맨드에서 명령형 오브젝트 구성으로 전환하기
령형 커맨드에서 명령형 오브젝트 구성으로 전환하기 위해
몇 가지 수동 단계를 포함한다.
다음과 같이 활성 오브젝트를 로컬 오브젝트 구성파일로 내보낸다.
kubectl get <종류>/<이름> -o yaml > <종류>_<이름>.yaml
수동으로 오브젝트 구성파일에서 상태 필드를 제거한다.
이후 오브젝트 관리를 위해, replace만 사용한다.
kubectl replace -f <종류>_<이름>.yaml
컨트롤러 셀렉터와 PodTemplate 레이블 삭제하기
경고: 컨트롤러에서 셀렉터를 업데이트하지 않도록 강력하게 권고한다.
권고되는 접근방법은 다른 의미론적 의미가 없는 컨트롤러 셀렉터의 의해서만
사용되는 단일, 불변의 PodTemplate 레이블로 정의하는 것이다.
파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 커맨드와 인자를
정의할 수 있다. 커맨드를 정의하기 위해서는, 파드 안에서 실행되는 컨테이너에
command 필드를 포함시킨다. 커맨드에 대한 인자를 정의하기 위해서는, 구성
파일에 args 필드를 포함시킨다. 정의한 커맨드와 인자들은 파드가 생성되고
난 이후에는 변경될 수 없다.
구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가
제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을
정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와
함께 사용된다.
참고:command 필드는 일부 컨테이너 런타임에서 entrypoint에 해당된다.
아래의 참고사항을 확인하자.
이 예제에서는 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성
파일에서 커맨드와 두 개의 인자를 정의한다.
apiVersion:v1kind:Podmetadata:name:envar-demolabels:purpose:demonstrate-envarsspec:containers:- name:envar-demo-containerimage:gcr.io/google-samples/node-hello:1.0env:- name:DEMO_GREETINGvalue:"Hello from the environment"- name:DEMO_FAREWELLvalue:"Such a sweet sorrow"
NAME READY STATUS RESTARTS AGE
envar-demo 1/1 Running 0 9s
파드의 컨테이너 환경 변수를 나열한다.
kubectl exec envar-demo -- printenv
출력은 아래와 비슷할 것이다.
NODE_VERSION=4.4.2
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
HOSTNAME=envar-demo
...
DEMO_GREETING=Hello from the environment
DEMO_FAREWELL=Such a sweet sorrow
참고:env 나 envFrom 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지
안에서 명시된 모든 환경 변수들을 오버라이딩한다.
참고: 환경 변수는 서로를 참조할 수 있는데, 이 때 순서에 주의해야 한다.
동일한 컨텍스트에서 정의된 다른 변수를 참조하는 변수는 목록의 뒤쪽에 나와야 한다.
또한, 순환 참조는 피해야 한다.
설정 안에서 환경 변수 사용하기
파드의 구성 파일 안에서 정의한 환경 변수는
파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이,
구성 파일 안의 다른 곳에서 사용할 수 있다.
아래의 구성 파일 예시에서, GREETING, HONORIFIC, 그리고
NAME 환경 변수들이 각각 Warm greetings to, The Most honorable,
그리고 Kubernetes로 설정되어 있다. 이 환경 변수들은
이후 env-print-demo 컨테이너에 전달되어 CLI 인자에서
사용된다.
쿠버네티스 디플로이먼트를 생성하고 퍼시스턴트볼륨클레임(PersistentVolumeClaim)을
사용하는 기존 퍼시스턴트볼륨에 연결하여 스테이트풀
애플리케이션을 실행할 수 있다. 예를 들어, 다음 YAML 파일은
MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로이먼트를 기술한다.
이 파일은 /var/lib/mysql에 대한 볼륨 마운트를 정의한 후에,
20G의 볼륨을 요청하는 퍼시트턴트볼륨클레임을 생성한다.
이 클레임은 요구 사항에 적합한 기존 볼륨이나
동적 프로비저너에 의해서 충족된다.
참고: config yaml 파일에 정의된 비밀번호는 안전하지 않다. 더 안전한 해결방법을 위해
쿠버네티스 시크릿
을 보자
apiVersion:v1kind:Servicemetadata:name:mysqlspec:ports:- port:3306selector:app:mysqlclusterIP:None---apiVersion:apps/v1kind:Deploymentmetadata:name:mysqlspec:selector:matchLabels:app:mysqlstrategy:type:Recreatetemplate:metadata:labels:app:mysqlspec:containers:- image:mysql:5.6name:mysqlenv:# Use secret in real usage- name:MYSQL_ROOT_PASSWORDvalue:passwordports:- containerPort:3306name:mysqlvolumeMounts:- name:mysql-persistent-storagemountPath:/var/lib/mysqlvolumes:- name:mysql-persistent-storagepersistentVolumeClaim:claimName:mysql-pv-claim
이전의 YAML 파일은 클러스터의 다른 파드가 데이터베이스에
접근할 수 있는 서비스를 생성한다. clusterIP: None
서비스 옵션을 사용하면 서비스의 DNS 이름을 직접 파드의 IP 주소로
해석하도록 처리한다. 이 방법은 서비스에서 연결되는 파드가 오직 하나 뿐이고,
파드의 수를 더 늘릴 필요가 없는 경우에 가장 적합하다.
서버에 접속하기 위하여 MySQL 클라이언트를 실행한다.
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword
이 명령어는 MySQL 클라이언트를 실행하는 파드를 클러스터에 생성하고,
서비스를 통하여 서버에 연결한다. 연결된다면, 스테이트풀
MySQL 데이터베이스가 실행 중임을 알 수 있다.
Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.
mysql>
업데이트하기
kubectl apply 명령을 사용하여 기존과 동일한 방식으로 디플로이먼트의
이미지나 다른 부분을 변경할 수 있다. 스테이트풀 애플리케이션과 관련하여 몇 가지
주의 사항이 있다.
애플리케이션을 스케일링하지 않는다. 이 설정은 단일 인스턴스 애플리케이션 전용이다.
기본적인 퍼시스턴트볼륨은 하나의 파드에서만 마운트할 수 있다.
클러스터 형태의 스테이트풀 애플리케이션에 대해서는
스테이트풀셋을 보자.
디플로이먼트 구성 YAML 파일에서 strategy:type: Recreate 를 사용한다. 이는 쿠버네티스가
롤링 업데이트를 사용하지 않도록 지시한다. 동시에 두 개 이상의 파드를 생성할
수 없으므로, 롤링 업데이트는 일어나지 않게 된다. Recreate 전략을 사용하면
변경된 구성으로 새로운 파드를 생성하기에 앞서 기존의 파드를 중단한다.
퍼시스턴트볼륨을 수동으로 프로비저닝한 경우라면,
동일하게 수동으로 삭제하고 기본 리소스도 해제해야 한다.
동적 프로비저너를 사용한 경우, 퍼시스턴트볼륨클레임이
삭제되었을 때에 퍼시스턴트볼륨 또한 자동으로 삭제된다.
일부 동적 프로비저너(EBS 와 PD와 같은)는
퍼시스턴트볼륨을 삭제할 때에 기본 리소스도 해제한다.
쿠버네티스에서 다른 리소스를 삭제하는 것과 같은 방식으로 스테이트풀셋을 삭제할 수 있다. kubectl delete 명령어를 사용하고 파일 또는 이름으로 스테이트풀셋을 지정하자.
kubectl delete -f <file.yaml>
kubectl delete statefulsets <statefulset-name>
스테이트풀셋 자체를 삭제한 후 연결된 헤드리스 서비스는 별도로 삭제해야 할 수도 있다.
kubectl delete service <service-name>
kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크기가 0으로 설정되고 이로 인해 스테이트풀셋에 포함된 모든 파드가 삭제된다. 파드가 아닌 스테이트풀셋만 삭제하려면, --cascade=false 옵션을 사용한다.
예시는 다음과 같다.
kubectl delete -f <file.yaml> --cascade=false
kubectl delete 에 --cascade=false 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 app=myapp 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
kubectl delete pods -l app=myapp
퍼시스턴트볼륨(PersistentVolume)
스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드가 종료된 후 PVC를 삭제하면 스토리지 클래스와 반환 정책에 따라 백업 퍼시스턴트볼륨 삭제가 트리거될 수 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다.
참고: PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
스테이트풀셋의 완벽한 삭제
연결된 파드를 포함해서 스테이트풀셋의 모든 것을 삭제하기 위해 다음과 같이 일련의 명령을 실행한다.
Horizontal Pod Autoscaler는 CPU 사용량
(또는 사용자 정의 메트릭,
아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션
컨트롤러(ReplicationController), 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. Horizontal
Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(DaemonSet))에는 적용되지 않는다.
Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
리소스는 컨트롤러의 동작을 결정한다.
컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
Horizontal Pod Autoscaler는 어떻게 작동하는가?
Horizontal Pod Autoscaler는 컨트롤러
관리자의 --horizontal-pod-autoscaler-sync-period 플래그(기본값은
15초)에 의해 제어되는 주기를 가진 컨트롤 루프로 구현된다.
각 주기 동안 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스
메트릭 API(파드 단위 리소스 메트릭 용)
또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
사용되는 비율을 생성한다.
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우,
파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는
해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링
알고리즘의 작동 방식에 대한 자세한 내용은 아래 알고리즘 세부 정보
섹션을 참조하기 바란다.
파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을
제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다.
오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는
단일 메트릭을 가져온다. 이 메트릭은 목표 값과
비교되어 위와 같은 비율을 생성한다. autoscaling/v2beta2 API
버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로
선택적으로 나눌 수 있다.
HorizontalPodAutoscaler는 보통 일련의 API 집합(metrics.k8s.io,
custom.metrics.k8s.io, external.metrics.k8s.io)에서 메트릭을 가져온다. metrics.k8s.io API는 대개 별도로
시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는
메트릭-서버를
참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다.
참고:
FEATURE STATE:Kubernetes v1.11 [deprecated]
힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨.
오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다.
스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.
하위 리소스 스케일에 대한 자세한 내용은
여기에서 확인할 수 있다.
알고리즘 세부 정보
가장 기본적인 관점에서, Horizontal Pod Autoscaler 컨트롤러는
원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로
작동한다.
원하는 레플리카 수 = ceil[현재 레플리카 수 * ( 현재 메트릭 값 / 원하는 메트릭 값 )]
예를 들어 현재 메트릭 값이 200m이고 원하는 값이
100m인 경우 200.0 / 100.0 == 2.0이므로 복제본 수가 두 배가
된다. 만약 현재 값이 50m 이면, 50.0 / 100.0 == 0.5 이므로
복제본 수를 반으로 줄일 것이다. 비율이 1.0(0.1을 기본값으로 사용하는
-horizontal-pod-autoscaler-tolerance 플래그를 사용하여
전역적으로 구성 가능한 허용 오차 내)에 충분히 가깝다면 스케일링을 건너 뛸 것이다.
targetAverageValue 또는 targetAverageUtilization가 지정되면,
currentMetricValue는 HorizontalPodAutoscaler의 스케일 목표
안에 있는 모든 파드에서 주어진 메트릭의 평균을 취하여 계산된다.
허용치를 확인하고 최종 값을 결정하기 전에, 파드
준비 상태와 누락된 메트릭을 고려한다.
삭제 타임 스탬프가 설정된 모든 파드(즉, 종료
중인 파드) 및 실패한 파드는 모두 폐기된다.
특정 파드에 메트릭이 누락된 경우, 나중을 위해 처리를 미뤄두는데, 이와
같이 누락된 메트릭이 있는 모든 파드는 최종 스케일 량을 조정하는데 사용된다.
CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (즉, 여전히
초기화 중인 경우) * 또는 * 파드의 최신 메트릭 포인트가 준비되기
전이라면, 마찬가지로 해당 파드는 나중에 처리된다.
기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지
않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로
전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다.
이 값은 --horizontal-pod-autoscaler-initial-readiness-delay 플래그로 설정되며, 기본값은 30초
이다. 일단 파드가 준비되고 시작된 후 구성 가능한 시간 이내이면,
준비를 위한 어떠한 전환이라도 이를 시작 시간으로 간주한다. 이
값은 --horizontal-pod-autoscaler-cpu-initialization-period 플래그로 설정되며
기본값은 5분이다.
현재 메트릭 값 / 원하는 메트릭 값 기본 스케일 비율은 나중에
사용하기로 되어 있거나 위에서 폐기되지 않은 남아있는 파드를 사용하여 계산된다.
누락된 메트릭이 있는 경우, 파드가 스케일 다운의 경우
원하는 값의 100%를 소비하고 스케일 업의 경우 0%를 소비한다고
가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인
스케일의 크기를 약화시킨다.
또한 아직-준비되지-않은 파드가 있는 경우 누락된 메트릭이나
아직-준비되지-않은 파드를 고려하지 않고 스케일 업했을 경우,
아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
보수적으로 가정하고 스케일 확장의 크기를 약화시킨다.
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에 사용
비율을 다시 계산한다. 새 비율이 스케일 방향을
바꾸거나, 허용 오차 내에 있으면 스케일링을 건너뛴다. 그렇지 않으면, 새
비율을 사용하여 스케일한다.
평균 사용량에 대한 원래 값은 새로운 사용 비율이 사용되는
경우에도 아직-준비되지-않은 파드 또는 누락된 메트릭에 대한
고려없이 HorizontalPodAutoscaler 상태를 통해 다시
보고된다.
HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은
각 메트릭에 대해 수행된 다음 원하는 레플리카 수 중 가장
큰 값이 선택된다. 이러한 메트릭 중 어떠한 것도 원하는
레플리카 수로 변환할 수 없는 경우(예 : 메트릭 API에서 메트릭을
가져오는 중 오류 발생) 스케일을 건너뛴다.
이는 하나 이상의 메트릭이
현재 값보다 높은 desiredReplicas 을 제공하는 경우
HPA가 여전히 확장할 수 있음을 의미한다.
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이
기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장
사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 --horizontal-pod-autoscaler-downscale-stabilization 플래그를 사용하여 설정할 수 있고, 기본값은 5분이다.
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
영향을 완만하게 한다.
API 오브젝트
Horizontal Pod Autoscaler는 쿠버네티스 autoscaling API 그룹의 API 리소스이다.
CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은
autoscaling/v1 API 버전에서 찾을 수 있다.
메모리 및 사용자 정의 메트릭에 대한 스케일링 지원을 포함하는 베타 버전은
autoscaling/v2beta2에서 확인할 수 있다. autoscaling/v2beta2에서 소개된
새로운 필드는 autoscaling/v1로 작업할 때 어노테이션으로 보존된다.
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 kubectl에 의해 표준 방식으로 지원된다.
kubectl create 커맨드를 사용하여 새로운 오토스케일러를 만들 수 있다.
kubectl get hpa로 오토스케일러 목록을 조회할 수 있고, kubectl describe hpa로 세부 사항을 확인할 수 있다.
마지막으로 kubectl delete hpa를 사용하여 오토스케일러를 삭제할 수 있다.
또한 Horizontal Pod Autoscaler를 생성할 수 있는 kubectl autoscale이라는 특별한 명령이 있다.
예를 들어 kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80을
실행하면 레플리케이션 셋 foo 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 80 %,
그리고 2와 5 사이의 레플리카 개수로 설정된다.
kubectl autoscale에 대한 자세한 문서는 여기에서 찾을 수 있다.
롤링 업데이트 중 오토스케일링
현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다.
Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다.
즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : kubectl rolling-update)
작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때,
Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다.
쿨-다운 / 지연에 대한 지원
Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 관리할 때,
평가된 메트릭의 동적인 특징 때문에 레플리카 수가
자주 변동할 수 있다. 이것은 때로는 스래싱 (thrashing) 이라고도 한다.
v1.6 부터 클러스터 운영자는 kube-controller-manager 컴포넌트의 플래그로
노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다.
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
필요성을 제거하였다.
--horizontal-pod-autoscaler-downscale-delay : 다운스케일이
안정화되기까지의 시간 간격을 지정한다.
Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고,
이 시간 간격에서의 가장 큰 크기에서만 작동한다.
기본값은 5분(5m0s)이다.
참고: 이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야
한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가
워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을
너무 짧게 설정하면, 레플리카셋의 크기가 평소와 같이 계속 스래싱될 수
있다.
리소스 메트릭 지원
모든 HPA 대상은 스케일링 대상에서 파드의 리소스 사용량을 기준으로 스케일링할 수 있다.
파드의 명세를 정의할 때는 cpu 및 memory 와 같은 리소스 요청을
지정해야 한다. 이것은 리소스 사용률을 결정하는 데 사용되며 HPA 컨트롤러에서 대상을
스케일링하거나 축소하는 데 사용한다. 리소스 사용률 기반 스케일링을 사용하려면 다음과 같은 메트릭 소스를
지정해야 한다.
이 메트릭을 사용하면 HPA 컨트롤러는 스케일링 대상에서 파드의 평균 사용률을
60%로 유지한다. 사용률은 파드의 요청된 리소스에 대한 현재 리소스 사용량 간의
비율이다. 사용률 계산 및 평균 산출 방법에 대한 자세한 내용은 알고리즘을
참조한다.
참고: 모든 컨테이너의 리소스 사용량이 합산되므로 총 파드 사용량이 개별 컨테이너 리소스 사용량을
정확하게 나타내지 못할 수 있다. 이로 인해 단일 컨테이너가
높은 사용량으로 실행될 수 있고 전체 파드 사용량이 여전히 허용 가능한 한도 내에 있기 때문에 HPA가 스케일링되지 않는
상황이 발생할 수 있다.
컨테이너 리소스 메트릭
FEATURE STATE:Kubernetes v1.20 [alpha]
HorizontalPodAutoscaler 는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의
리소스 사용량을 추적할 수 있는 컨테이너 메트릭 소스도 지원한다.
이를 통해 특정 파드에서 가장 중요한 컨테이너의 스케일링 임계값을 구성할 수 있다.
예를 들어 웹 애플리케이션 프로그램과 로깅 사이드카가 있는 경우 사이드카 컨테이너와 해당 리소스 사용을 무시하고
웹 애플리케이션의 리소스 사용을 기준으로 스케일링할 수 있다.
대상 리소스를 다른 컨테이너 세트를 사용하여 새 파드 명세를 갖도록 수정하는 경우
새로 추가된 컨테이너도 스케일링에 사용해야 한다면 HPA 사양을 수정해야 한다.
메트릭 소스에 지정된 컨테이너가 없거나 파드의 하위 집합에만 있는 경우
해당 파드는 무시되고 권장 사항이 다시 계산된다. 계산에 대한 자세한 내용은 알고리즘을
을 참조한다. 컨테이너 리소스를 오토스케일링에 사용하려면 다음과 같이
메트릭 소스를 정의한다.
위의 예에서 HPA 컨트롤러는 모든 파드의 application 컨테이너에 있는 CPU의 평균 사용률이
60%가 되도록 대상을 조정한다.
참고:
HorizontalPodAutoscaler가 추적하는 컨테이너의 이름을 변경하는 경우
특정 순서로 변경을 수행하여 변경 사항이 적용되는 동안 스케일링을 계속 사용할 수 있고
효율적으로 유지할 수 있다. 컨테이너를 정의하는 리소스(예: 배포)를
업데이트하기 전에 연결된 HPA를 업데이트하여 새 컨테이너 이름과 이전 컨테이너 이름을
모두 추적해야 한다. 이러한 방식으로 HPA는 업데이트 프로세스 전반에 걸쳐 스케일링 권장 사항을
계산할 수 있다.
컨테이너 이름 변경을 워크로드 리소스로 롤아웃한 후에는 HPA 사양에서
이전 컨테이너 이름을 제거하여 정리한다.
멀티 메트릭을 위한 지원
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. autoscaling/v2beta2 API
버전을 사용하여 Horizontal Pod Autoscaler가 스케일을 조정할 멀티 메트릭을 지정할 수 있다. 그런 다음 Horizontal Pod
Autoscaler 컨트롤러가 각 메트릭을 평가하고, 해당 메트릭을 기반으로 새 스케일을 제안한다.
제안된 스케일 중 가장 큰 것이 새로운 스케일로 사용된다.
사용자 정의 메트릭을 위한 지원
참고: 쿠버네티스 1.2는 특수 어노테이션을 사용하여 애플리케이션 관련 메트릭을 기반으로 하는 스케일의 알파 지원을 추가했다.
쿠버네티스 1.6에서는 이러한 어노테이션 지원이 제거되고 새로운 오토스케일링 API가 추가되었다. 이전 사용자 정의
메트릭 수집 방법을 계속 사용할 수는 있지만, Horizontal Pod Autoscaler에서는 이 메트릭을 사용할 수 없다. 그리고
Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용자 정의 메트릭을 지정하는 이전 어노테이션을 사용할 수 없다.
쿠버네티스 1.6에서는 Horizontal Pod Autoscaler에서 사용자 정의 메트릭을 사용할 수 있도록 지원한다.
autoscaling/v2beta2 API에서 사용할 Horizontal Pod Autoscaler에 대한 사용자 정의 메트릭을 추가 할 수 있다.
그리고 쿠버네티스는 새 사용자 정의 메트릭 API에 질의하여 적절한 사용자 정의 메트릭의 값을 가져온다.
v1.18
부터 v2beta2 API는 HPA behavior 필드를 통해
스케일링 동작을 구성할 수 있다.
동작은 behavior 필드 아래의 scaleUp 또는 scaleDown
섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는
스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는
양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면
스케일링 중 레플리카 변경 속도를 제어할 수 있다.
스케일링 정책
스펙의 behavior 섹션에 하나 이상의 스케일링 폴리시를 지정할 수 있다.
폴리시가 여러 개 지정된 경우 가장 많은 양의 변경을
허용하는 정책이 기본적으로 선택된 폴리시이다. 다음 예시는 스케일 다운 중 이
동작을 보여준다.
periodSeconds 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
첫 번째 정책은 (파드들) 이 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
두 번째 정책은 비율 로 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
기본적으로 가장 많은 변경을 허용하는 정책이 선택되기에 두 번째 정책은
파드의 레플리카 수가 40개를 초과하는 경우에만 사용된다. 레플리카가 40개 이하인 경우 첫 번째 정책이 적용된다.
예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는
경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때
다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의
각 루프에서 변경될 파드의 수는 현재 레플리카의 수에 따라 재계산된다. 레플리카의 수가 40
미만으로 떨어지면 첫 번째 폴리시 (파드들) 가 적용되고 한번에
4개의 레플리카가 줄어든다.
확장 방향에 대해 selectPolicy 필드를 확인하여 폴리시 선택을 변경할 수 있다.
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 최소(Min)로 값을 설정한다.
값을 Disabled 로 설정하면 해당 방향으로 스케일링이 완전히
비활성화 된다.
안정화 윈도우
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
다음의 예시에서 scaleDown 에 대해 안정화 윈도우가 지정되어있다.
scaleDown:stabilizationWindowSeconds:300
메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은
이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다.
위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다.
기본 동작
사용자 지정 스케일링을 사용하려면 일부 필드를 지정해야 한다. 사용자 정의해야
하는 값만 지정할 수 있다. 이러한 사용자 지정 값은 기본값과 병합된다. 기본값은 HPA
알고리즘의 기존 동작과 일치한다.
안정화 윈도우의 스케일링 다운의 경우 300 초 (또는 제공된
경우--horizontal-pod-autoscaler-downscale-stabilization 플래그의 값)이다. 스케일링 다운에서는 현재
실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링
대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다.
스케일링 업에는 안정화 윈도우가 없다. 메트릭이 대상을 스케일 업해야 한다고 표시된다면 대상이 즉시 스케일 업된다.
두 가지 폴리시가 있다. HPA가 정상 상태에 도달 할 때까지 15초 마다
4개의 파드 또는 현재 실행 중인 레플리카의 100% 가 추가된다.
예시: 다운스케일 안정화 윈도우 변경
사용자 지정 다운스케일 안정화 윈도우를 1분 동안 제공하기 위해
다음 동작이 HPA에 추가된다.
behavior:scaleDown:stabilizationWindowSeconds:60
예시: 스케일 다운 비율 제한
HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해
다음 동작이 HPA에 추가된다.
마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
전략을 추가할 수 있다.
분당 5개 이하의 파드가 제거되지 않도록, 고정 크기가 5인 두 번째 축소
정책을 추가하고, selectPolicy 를 최소로 설정하면 된다. selectPolicy 를 Min 으로 설정하면
자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미한다.
selectPolicy 의 Disabled 값은 주어진 방향으로의 스케일링을 끈다.
따라서 다운 스케일링을 방지하기 위해 다음 폴리시가 사용된다.
behavior:scaleDown:selectPolicy:Disabled
암시적 유지 관리 모드 비활성화
HPA 구성 자체를 변경할 필요없이 대상에 대한
HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한
레플리카 수가 0으로 설정되고, HPA의 최소 레플리카 수가 0 보다 크면, 대상의
의도한 레플리카 수 또는 HPA의 최소 레플리카 수를 수동으로 조정하여
다시 활성화할 때까지 HPA는 대상 조정을
중지한다(그리고 ScalingActive 조건 자체를 false로 설정).
Horizontal Pod Autoscaler는
CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다.
이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다.
Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는
Horizontal Pod Autoscaler 사용자 가이드를 참고하기 바란다.
시작하기 전에
이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다.
메트릭 서버 모니터링을 클러스터에 배포하여
메트릭 API를 통해 메트릭을 제공해야 한다.
Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 방법에 대해 배우려면,
메트릭-서버 문서를 참고한다.
Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우,
버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가
사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다.
마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우,
버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부
메트릭 API와 통신이 가능해야 한다.
자세한 사항은 Horizontal Pod Autoscaler 사용자 가이드를 참고하길 바란다.
php-apache 서버 구동 및 노출
Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. Dockerfile은 다음과 같다.
FROM php:5-apacheCOPY index.php /var/www/html/index.phpRUN chmod a+rx index.php
deployment.apps/php-apache created
service/php-apache created
Horizontal Pod Autoscaler 생성
이제 서비스가 동작중이므로,
kubectl autoscale를 사용하여 오토스케일러를 생성한다.
다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를
1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다.
간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다.
(kubectl run으로 각 파드는 200 밀리코어까지 요청할 수 있고,
따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다).
이에 대한 자세한 알고리즘은 여기를 참고하기 바란다.
targetCPUUtilizationPercentage 필드가 metrics 배열로 대체되었다.
CPU 사용량 메트릭은 resource metric 으로 파드 컨테이너 자원의 백분율로 표현된다.
CPU 외에 다른 메트릭을 지정할 수 있는데, 기본적으로 지원되는 다른 메트릭은 메모리뿐이다.
이 자원들은 한 클러스터에서 다른 클러스터로 이름을 변경할 수 없으며,
metrics.k8s.io API가 가용한 경우 언제든지 사용할 수 있어야 한다.
또한, Utilization 대신 AverageValue의 target 타입을,
그리고 target.averageUtilization 대신 target.averageValue로 설정하여
자원 메트릭을 퍼센트 대신 값으로 명시할 수 있다.
파드 메트릭과 오브젝트 메트릭 두 가지의 사용자 정의 메트릭 이 있다.
파드 메트릭과 오브젝트 메트릭. 이 메트릭은 클러스터에 특화된 이름을 가지고 있으며,
더 고급화된 클러스터 모니터링 설정이 필요하다.
이러한 대체 메트릭 타입중 첫 번째는 파드 메트릭 이다.
이 메트릭은 파드들을 설명하고, 파드들간의 평균을 내며,
대상 값과 비교하여 레플리카 개수를 결정한다.
이것들은 AverageValue의 target만을 지원한다는 것을 제외하면,
자원 메트릭과 매우 유사하게 동작한다.
두 번째 대체 메트릭 타입은 오브젝트 메트릭 이다.
이 메트릭은 파드를 기술하는 대신에 동일한 네임스페이스 내에 다른 오브젝트를 표현한다.
이 메트릭은 반드시 오브젝트로부터 가져올 필요는 없다. 단지 오브젝트를 기술할 뿐이다.
오브젝트 메트릭은 Value과 AverageValue의 target 타입을 지원한다.
Value를 사용할 경우 대상은 API로부터 반환되는 메트릭과 직접 비교된다.
AverageValue를 사용할 경우, 대상 값과 비교되기 이전에 사용자 정의 메트릭 API로부터 반환된 값은 파드의 개수로 나눠진다.
다음은 requests-per-second 메트릭을 YAML로 기술한 예제이다.
이후, HorizontalPodAutoscaler는 각 파드가 요청 된 약 50%의 CPU 사용률을 소모하는지,
초당 1000 패킷을 처리하는지,
메인-루트 인그레스 뒤의 모든 파드들이 초당 10000 요청을 처리하는지 확인한다.
보다 구체적인 메트릭을 기초로한 오토스케일링
많은 메트릭 파이프라인들을 사용하면 이름 또는 labels 이라 불리는 추가적인 식별자로 메트릭을 설명할 수 있다.
그리고, 모든 비 자원 메트릭 타입(파드, 오브젝트 그리고 아래 기술된 외부 타입)에 대해,
메트릭 파이프라인으로 전달되는 추가 레이블 셀렉터를 지정할 수 있다.
예를 들면, verb 레이블로 http_requests 메트릭을 수집하는 경우,
다음과 같이 메트릭 블록을 지정하여 GET 요청에 대해 크기를 조정할 수 있다.
이 셀렉터는 쿠버네티스의 레이블 셀렉터와 동일한 문법이다.
모니터링 파이프라인은 네임과 셀렉터가 여러 시리즈와 일치하는 경우,
해당 여러 시리즈를 단일 값으로 축소하는 방법을 결정한다.
셀렉터는 부가적인 속성이며,
대상 오브젝트(Pods 타입의 대상 파드, Object 타입으로 기술된 오브젝트)가 아닌 메트릭을 선택할 수 없다.
쿠버네티스 오브젝트와 관련이 없는 메트릭을 기초로한 오토스케일링
쿠버네티스 위에서 동작하는 애플리케이션은, 쿠버네티스 클러스터의 어떤 오브젝트와도 관련이 없는 메트릭에 기반하여
오토스케일링을 할 수도 있다.
예로, 쿠버네티스 네임스페이스와 관련이 없는 서비스를 기초로한 메트릭을 들 수 있다.
쿠버네티스 버전 1.10 포함 이후 버전에서, 외부 메트릭 을 사용하여 이러한 유스케이스를 해결할 수 있다.
외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다.
이 설치는 사용자 정의 메트릭과 유사하다.
외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다.
위의 예제처럼 name과 selector를 갖는 metric 블록을 명시하고,
Object 대신에 External 메트릭 타입을 사용한다.
만일 여러 개의 시계열이 metricSelector와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
외부 메트릭들은 Value와 AverageValue 대상 타입을 모두 지원하고,
Object 타입을 사용할 때와 똑같이 동작한다.
예를 들면 애플리케이션이 호스팅 된 대기열 서비스에서 작업을 처리하는 경우,
다음과 같이 HorizontalPodAutoscaler 매니퍼스트에 30개의 미해결 태스크 당 한 개의 워커를 지정하도록 추가할 수 있다.
가능하다면, 외부 메트릭 대신 사용자 정의 메트릭 대상 타입을 사용하길 권장한다.
왜냐하면, 클러스터 관리자가 사용자 정의 메트릭 API를 보안관점에서 더 쉽게 보호할 수 있기 때문이다.
외부 메트릭 API는 잠재적으로 어떠한 메트릭에도 접근할 수 있기에, 클러스터 관리자는 API를 노출시킬때 신중해야 한다.
부록: Horizontal Pod Autoscaler 상태 조건
HorizontalPodAutoscaler의 autoscaling/v2beta2 형식을 사용하면,
HorizontalPodAutoscaler에서 쿠버네티스가 설정한 상태 조건 을 확인할 수 있다.
이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지,
어떤 방식으로든 제한되어 있는지 여부를 나타낸다.
이 조건은 status.conditions에 나타난다.
HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 kubectl describe hpa를 사용할 수 있다.
kubectl describe hpa cm-test
Name: cm-test
Namespace: prom
Labels: <none>
Annotations: <none>
CreationTimestamp: Fri, 16 Jun 2017 18:09:22 +0000
Reference: ReplicationController/cm-test
Metrics: ( current / target )
"http_requests" on pods: 66m / 500m
Min replicas: 1
Max replicas: 4
ReplicationController pods: 1 current / 1 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from pods metric http_requests
ScalingLimited False DesiredWithinRange the desired replica count is within the acceptable range
Events:
이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다.
첫 번째 AbleToScale는 HPA가 스케일을 가져오고 업데이트할 수 있는지,
백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다.
두 번째 ScalingActive는 HPA가 활성화되어있는지(즉 대상 레플리카 개수가 0이 아닌지),
원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 False 인 경우,
일반적으로 메트릭을 가져오는데 문제가 있다.
마지막으로, 마지막 조건인 ScalingLimited는
원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다.
이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다.
부록: 수량
HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은
쿠버네티스에서 사용하는
수량 숫자 표기법을 사용한다.
예를 들면, 10500m 수량은 10진법 10.5으로 쓰인다.
메트릭 API들은 가능한 경우 접미사 없이 정수를 반환하며,
일반적으로 수량을 밀리단위로 반환한다.
10진수로 표현했을때, 1과 1500m 또는 1과 1.5 로 메트릭 값을 나타낼 수 있다.
부록: 다른 가능한 시나리오
명시적으로 오토스케일러 만들기
HorizontalPodAutoscaler를 생성하기 위해 kubectl autoscale 명령어를 사용하지 않고,
명시적으로 다음 파일을 사용하여 만들 수 있다.
각각의 경우, 파드의 서비스 어카운트 자격 증명은 API 서버와
안전하게 통신하는 데 사용된다.
REST API에 직접 접근
파드에서 실행되는 동안, 쿠버네티스 apiserver는 default 네임스페이스에서 kubernetes라는
서비스를 통해 접근할 수 있다. 따라서, 파드는 kubernetes.default.svc
호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는
이를 자동으로 수행한다.
API 서버를 인증하는 권장 방법은 서비스 어카운트
자격 증명을 사용하는 것이다. 기본적으로, 파드는
서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은
해당 파드에 있는 각 컨테이너의 파일시스템 트리의
/var/run/secrets/kubernetes.io/serviceaccount/token 에 있다.
사용 가능한 경우, 인증서 번들은 각 컨테이너의
파일시스템 트리의 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 에 배치되며,
API 서버의 제공 인증서를 확인하는 데 사용해야 한다.
마지막으로, 네임스페이스가 지정된 API 작업에 사용되는 기본 네임스페이스는 각 컨테이너의
/var/run/secrets/kubernetes.io/serviceaccount/namespace 에 있는 파일에 배치된다.
kubectl 프록시 사용
공식 클라이언트 라이브러리 없이 API를 쿼리하려면, 파드에서
새 사이드카 컨테이너의 명령으로
kubectl proxy 를 실행할 수 있다. 이런 식으로, kubectl proxy 는
API를 인증하고 이를 파드의 localhost 인터페이스에 노출시켜서, 파드의
다른 컨테이너가 직접 사용할 수 있도록 한다.
프록시를 사용하지 않고 접근
인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시 사용을
피할 수 있다. 내부 인증서는 연결을 보호한다.
# 내부 API 서버 호스트 이름을 가리킨다APISERVER=https://kubernetes.default.svc
# 서비스어카운트(ServiceAccount) 토큰 경로SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
# 이 파드의 네임스페이스를 읽는다NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)# 서비스어카운트 베어러 토큰을 읽는다TOKEN=$(cat ${SERVICEACCOUNT}/token)# 내부 인증 기관(CA)을 참조한다CACERT=${SERVICEACCOUNT}/ca.crt
# TOKEN으로 API를 탐색한다
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
참고: 크론 잡, 특히 해당 잡의 .spec 에 대한 모든 수정 사항은 다음 번 실행에만 적용된다.
스케줄
.spec.schedule 은 .spec 의 필수 필드이다.
이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 0 * * * * 또는 @hourly 와 같이 크론 형식의 문자열을 받아들인다.
이 형식은 확장된 vixie cron 스텝(step) 값도 포함한다. 이 내용은
FreeBSD 매뉴얼에 설명되어 있다.
스텝 값은 범위(range)와 함께 사용할 수 있다. 범위 뒤에 /<number> 를
지정하여 범위 내에서 숫자만큼의 값을 건너뛴다. 예를 들어,
시간 필드에 0-23/2 를 사용하여 매 2시간마다 명령 실행을
지정할 수 있다(V7 표준의 대안은 0,2,4,6,8,10,12,14,16,18,20,22
이다). 별표(asterisk) 뒤에 붙이는 스텝도 허용되며,
"2시간마다"라고 지정하고 싶으면, 간단히 */2 를 사용하면 된다.
참고: 스케줄에서 물음표(?)는 별표 * 와 동일한 의미를 가지며, 주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
잡 템플릿
.spec.jobTemplate 은 잡에 대한 템플릿이며, 이것은 필수 필드다.
이것은 중첩되고 apiVersion 이나 kind 가 없는 것을 제외하고 잡과 정확히 같은 스키마를 가진다.
잡 .spec 을 작성하는 것에 대한 내용은 잡 명세 작성하기를 참고한다.
시작 기한
.spec.startingDeadlineSeconds 필드는 선택 사항이다.
어떤 이유로든 스케줄된 시간을 놓친 경우 잡의 시작 기한을 초 단위로 나타낸다.
기한이 지나면, 크론 잡이 잡을 시작하지 않는다.
이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다.
이 필드를 지정하지 않으면, 잡에 기한이 없다.
크론잡 컨트롤러는 크론 잡에 대해 얼마나 많은 스케줄이 누락되었는지를 계산한다. 누락된 스케줄이 100개를 초과 한다면, 크론 잡은 더이상 스케줄되지 않는다. .spec.startingDeadlineSeconds 이 설정되지 않았다면, 크론잡 컨트롤러는 status.lastScheduleTime 부터 지금까지 누락된 스케줄을 계산한다.
예를 들어, 하나의 크론 잡이 1분마다 실행되도록 설정되어 있고, 크론잡의 status.lastScheduleTime 은 새벽 5:00시이지만, 지금은 오전 7:00시라고 가정하자. 즉 120개의 스케줄이 누락되었다는 것이고, 그래서 크론 잡은 더이상 스케줄되지 않는다.
.spec.startingDeadlineSeconds 필드가 (null이 아닌) 값으로 설정되어 있다면, 크론잡 컨트롤러는 .spec.startingDeadlineSeconds 의 값으로부터 지금까지 얼마나 많은 잡이 누락되었는지를 계산한다.
예를 들어, 200 으로 설정되었다면, 지난 200초 동안 누락된 스케줄이 몇 번 발생했는지 계산한다. 이 경우, 지난 200초 동안 누락된 스케줄이 100개가 넘으면, 크론 잡이 더이상 스케줄되지 않는다.
동시성 정책
.spec.concurrencyPolicy 필드도 선택 사항이다.
이것은 이 크론 잡에 의해 생성된 잡의 동시 실행을 처리하는 방법을 지정한다.
명세는 다음의 동시성 정책 중 하나만 지정할 수 있다.
Allow(기본값): 크론 잡은 동시에 실행되는 잡을 허용한다.
Forbid: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
Replace: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
참고로 동시성 정책은 동일한 크론 잡에 의해 생성된 잡에만 적용된다.
크론 잡이 여러 개인 경우, 각각의 잡은 항상 동시에 실행될 수 있다.
일시 정지
.spec.suspend 필드도 선택 사항이다.
true 로 설정되면, 모든 후속 실행이 일시 정지된다.
이 설정은 이미 시작된 실행에는 적용되지 않는다.
기본값은 false이다.
주의: 스케줄된 시간 동안 잡이 일시 정지되어 있다면 누락된 잡으로 간주한다.
시작 기한 없이 기존의 크론 잡에 대해 .spec.suspend 가 true 에서 false 로 변경되면, 누락된 잡들이 즉시 스케줄된다.
잡 히스토리 한도
.spec.successfulJobsHistoryLimit 와 .spec.failedJobsHistoryLimit 필드는 선택 사항이다.
이들 필드는 기록을 보관해야 하는 완료 및 실패한 잡의 개수를 지정한다.
기본적으로, 각각 3과 1로 설정된다. 한도를 0 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.
4.7.2 - 확장을 사용한 병렬 처리
이 태스크는 공통 템플릿을 기반으로 하는 여러 개의 잡(Job)을
실행하는 것을 보여준다. 이 접근 방식을 사용하여 일괄 작업을 병렬로 처리할 수
있다.
이 예에는 apple, banana 그리고 cherry 세 항목만 있다.
샘플 잡들은 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.
# 생성한 잡 제거# 클러스터가 자동으로 잡이 있던 파드를 정리
kubectl delete job -l jobgroup=jobexample
실제 워크로드에서 잡 사용하기
실제 유스케이스에서, 각 잡은 동영상의 프레임을 렌더링하거나, 데이터베이스에서 행 범위를
처리하는 것과 같은 상당한 규모의 계산을 수행한다. 동영상을 렌더링하는 경우 프레임 번호에
$ITEM 을 설정한다. 데이터베이스에서 행을 처리하는
경우, 처리할 데이터베이스 행의 범위를 나타내도록 $ITEM 을 설정한다.
이번 태스크에서, 로그를 가져와 파드에서 출력 결과를 수집하는 명령어를
실행했다. 실제 유스케이스에서, 잡의 각 파드는 완료하기 전에 출력 결과를
내구성있는 스토리지에 기록한다. 각 잡에 대해 퍼시스턴트볼륨(PersistentVolume)을
사용하거나 외장 스토리지 서비스를 사용할 수 있다. 예를 들어, 동영상의 프레임을 렌더링하는 경우,
HTTP를 사용하여 렌더링된 프레임 데이터를 각 프레임에 대한 다른 URL을 사용해서 URL에 PUT
한다.
잡과 파드의 레이블
잡을 생성한 후, 쿠버네티스는 한 잡의 파드를 다른 잡의 파드와 구별하기 위해서
추가 레이블을
자동으로 추가한다.
이 예시에서, 각 잡과 잡의 파드 템플릿은 jobgroup=jobexample
레이블을 갖는다.
쿠버네티스 자체는 jobgroup 이라는 레이블에 신경쓰지 않는다. 템플릿에서
생성한 모든 잡에 대해 레이블을 설정하면 한번에 모든 잡을 편리하게
조작할 수 있다.
첫 번째 예제에서 템플릿을 사용해서
여러 잡을 생성했다. 템플릿은 각 파드도 동일한 레이블을 가질 수 있도록 보장하므로,
단일 명령어로 이러한 템플릿 기반 잡들의 모든 파드에서 확인할 수 있다.
참고: 레이블 키 jobgroup 은 특별하거나 예약되어 있지 않다.
고유한 레이블링 체계를 선택할 수 있다.
원하는 경우 사용할 수 있는
권장 레이블이 있다.
대안
많은 수의 잡 오브젝트의 생성을 계획 중이라면, 아마도 다음의 사항을 파악하게 될 것이다.
레이블을 사용해도, 너무 많은 잡을 관리하는 것은 번거롭다.
일괄적으로 많은 잡을 생성하는 경우, 쿠버네티스 컨트롤 플레인에
높음 부하를 가할 수 있다. 대안으로, 쿠버네티스 API 서버가
속도를 제한하여 429 상태의 사용자 요청을 일시적으로 거부할 수 있다.
사용자는 잡의 리소스 쿼터로
제한될 수 있다. 한번에 많은 작업을 생성하면 API 서버가 사용자의 요청 중
일부를 영구적으로 거부한다.
아주 많은 잡 오브젝트를 생성하지 않고 많은 양의 작업을 처리하는데 사용할 수 있는
다른 잡 패턴도
있다.
이제, 메시지 대기열을 이용해 실험할 수 있다. 임시
대화형 파드를 만들어 그 위에 도구들을 설치하고,
대기열을 실험해본다.
먼저 임시 대화형 파드를 만든다.
# 임시 대화형 컨테이너를 만든다.
kubectl run -i --tty temp --image ubuntu:18.04
Waiting for pod default/temp-loe07 to be running, status is Pending, pod ready: false
... [ previous line repeats several times .. hit return when it stops ] ...
# rabbitmq-service가 쿠버네티스로부터 주어진 DNS 이름을 갖는다.
root@temp-loe07:/# nslookup rabbitmq-service
Server: 10.0.0.10
Address: 10.0.0.10#53
Name: rabbitmq-service.default.svc.cluster.local
Address: 10.0.147.152
# 주소는 다를 수 있다.
만약 Kube-DNS가 적절히 구축되지 않았다면, 전 단계 작업이 작동하지 않을 수 있다.
환경 변수를 통해서도 서비스 IP를 찾을 수 있다.
# env | grep RABBIT | grep HOST
RABBITMQ_SERVICE_SERVICE_HOST=10.0.147.152
# 주소는 다를 수 있다.
다음으로 대기열을 생성하고, 메시지를 발행하고 사용할 수 있는지 확인한다.
# 다음 줄에서, rabbitmq-service는 rabbitmq-service에 접근할 수 있는 # 호스트네임이다. 5672는 rabbitmq의 표준 포트이다.
root@temp-loe07:/# exportBROKER_URL=amqp://guest:guest@rabbitmq-service:5672
# 만약 전 단계에서 "rabbitmq-service"가 주소로 변환되지 않는다면,# 이 커맨드를 대신 사용하면 된다.# root@temp-loe07:/# BROKER_URL=amqp://guest:guest@$RABBITMQ_SERVICE_SERVICE_HOST:5672# 이제 대기열을 생성한다.
root@temp-loe07:/# /usr/bin/amqp-declare-queue --url=$BROKER_URL -q foo -d
foo
# 대기열에 메시지를 하나 발행한다.
root@temp-loe07:/# /usr/bin/amqp-publish --url=$BROKER_URL -r foo -p -b Hello
# 다시 메시지를 돌려받는다.
root@temp-loe07:/# /usr/bin/amqp-consume --url=$BROKER_URL -q foo -c 1 cat &&echo
Hello
root@temp-loe07:/#
마지막 커맨드에서, amqp-consume 도구는 대기열로부터 하나의 메시지를
받고(-c 1), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, cat 프로그램이 표준입력으로부터 받은 값을 출력하고, echo가 캐리지 리턴을 더해주어
출력 결과가 보여진다.
작업으로 대기열 채우기
이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 문자열을
출력하는 것이다.
실제로 사용할 때는, 메시지의 내용이 다음과 같을 수 있다.
처리되어야 하는 파일들의 이름
프로그램의 추가 플래그
데이터베이스 테이블의 키(key) 범위
시뮬레이션의 구성 파라미터
렌더링해야 하는 씬(scene)의 프레임 번호
실제로는, 잡의 모든 파드에서 읽기-전용 모드로 필요한 큰 데이터가
있다면, 일반적으로 그 데이터를 NFS와 같은 공유 파일시스템에 넣고
모든 파드에 읽기 전용으로 마운트하거나, 파드 안에 있는 프로그램이 기본적으로 HDFS와 같은
클러스터 파일시스템으로부터 데이터를 불러들인다.
본 예제에서는, 대기열을 만들고 amqp 커맨드라인 도구를 이용해 대기열을 채울 것이다.
실제로는, amqp 라이브러리를 이용해 대기열을 채우는 프로그램을 작성하게 된다.
#!/usr/bin/env python# 표준 출력만 출력하고 10초 동안 대기한다.importsysimporttimeprint("Processing "+ sys.stdin.readlines()[0])
time.sleep(10)
스크립트에 실행 권한을 준다.
chmod +x worker.py
이제 이미지를 빌드한다. 만약 소스 트리 안에서 작업하고
있다면, examples/job/work-queue-1로 디렉터리를 옮긴다.
아니면, 임시 디렉터리를 만들고, 그 디렉터리로 옮긴다.
Dockerfile과
worker.py를 다운로드한다.
위 두 경우 모두, 다음의 명령을 이용해 이미지를 빌드한다.
docker build -t job-wq-1 .
도커 허브를 이용하기 위해, 앱 이미지를
사용자의 username으로 태깅하고 아래의 명령어를 이용해 허브에 푸시한다.
<username>을 사용자의 허브 username으로 대체한다.
docker tag job-wq-1 <username>/job-wq-1
docker push <username>/job-wq-1
만약 구글 컨테이너
레지스트리를 이용하고 있다면,
앱 이미지를 사용자의 프로젝트 ID를 이용해 태깅하고, GCR에 푸시한다.
<proejct> 부분을 사용자의 프로젝트 ID로 대체한다.
docker tag job-wq-1 gcr.io/<project>/job-wq-1
gcloud docker -- push gcr.io/<project>/job-wq-1
잡 정의
다음은 잡 정의이다. 잡의 사본을 만들고 위에서 정한 이름에 맞게
이미지를 수정하고, 파일 이름을 ./job.yaml이라 정한다.
이 예시에서는, 각 파드가 대기열로부터 얻은 하나의 아이템을 수행하고 종료한다.
그래서, 잡의 완료 횟수가 완료된 작업 아이템의 숫자에 대응한다.
예시에서 .spec.completions: 8이라 정한 것도, 대기열에 8개의 아이템을 넣었기 때문이다.
잡 실행
이제 잡을 실행한다.
kubectl apply -f ./job.yaml
이제 조금 기다린 다음, 잡을 확인한다.
kubectl describe jobs/job-wq-1
Name: job-wq-1
Namespace: default
Selector: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
job-name=job-wq-1
Annotations: <none>
Parallelism: 2
Completions: 8
Start Time: Wed, 06 Sep 2017 16:42:02 +0800
Pods Statuses: 0 Running / 8 Succeeded / 0 Failed
Pod Template:
Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
job-name=job-wq-1
Containers:
c:
Image: gcr.io/causal-jigsaw-637/job-wq-1
Port:
Environment:
BROKER_URL: amqp://guest:guest@rabbitmq-service:5672
QUEUE: job1
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
───────── ──────── ───── ──── ───────────── ────── ────── ───────
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-hcobb
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-weytj
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-qaam5
27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-b67sr
26s 26s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-xe5hj
15s 15s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-w2zqe
14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-d6ppa
14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-p17e0
모든 파드가 성공했다. 야호.
대안
이러한 접근은 "워커" 프로그램을 작업 대기열에 맞게 수정하지 않아도
된다는 장점이 있다.
이 접근을 이용하려면, 메시지 대기열 서비스를 실행해야만 한다.
만약 메시지 대기열 서비스를 실행하는 게 불편하다면,
다른 잡 패턴을 고려해볼 수 있다.
이 접근은 모든 작업 아이템에 대해 파드를 생성한다. 만약 작업 아이템이 오직 몇 초밖에 걸리지 않는 작업이라면,
매 작업마다 파드를 생성하는 것은 아주 큰 오버헤드를 더할 수 있다. 하나의 파드가
여러 작업 아이템을 수행하는 이 예제를 고려해보자.
이 예제에서는, amqp-consume 유틸리티를 이용해 대기열로부터 메시지를 읽어
실제 프로그램을 실행했다. 이러면 메시지 대기열을 이용하기 위해 프로그램을 수정하지
않아도 된다는 장점이 있다.
다른 예제는
클라이언트 라이브러리를 이용해 작업 대기열과 소통하는 방법을 보여준다.
주의 사항
만약 작업 완료 수가 대기열에 있는 아이템의 숫자보다 적게 설정되면,
모든 아이템 처리되지 않는다.
만약 작업 완료 수가 큐에 있는 아이템의 숫자보다 많게 설정되면,
대기열에 있는 아이템이 모두 처리되어도, 잡이 완료됐다고 표시되지
않고, 메시지를 기다리는 과정에서 막히는 파드를
추가적으로 실행시킨다.
이 패턴에서는 경쟁 상태(race)가 잘 나타나지 않는다. 만약 amqp-consume 명령으로부터
메시지가 인정되는 시간과 컨테이너가 성공적으로 종료되는
시간 사이에 컨테이너가 종료되거나, kubelet이 api-server에게 파드가 성공했음을 알리기 전에
노드가 비정상적으로 종료되면, 대기열의 모든 아이템이 처리되었다 해도,
잡이 완료되었다고 표시되지 않는다.
4.7.4 - 작업 대기열을 사용한 정밀 병렬 처리
이 예에서는, 지정된 파드에서 여러 병렬 워커 프로세스가 있는
쿠버네티스 잡(Job)을 실행한다.
이 예에서는, 각 파드가 생성될 때, 작업 대기열에서 하나의 작업 단위를
선택하여, 처리하고, 대기열이 비워질 때까지 반복한다.
이 예에서의 단계에 대한 개요는 다음과 같다.
작업 대기열을 보관할 스토리지 서비스를 시작한다. 이 예에서는, Redis를 사용하여
작업 항목을 저장한다. 이전 예에서는, RabbitMQ를 사용했다. 이 예에서는, AMQP가 길이가
정해져 있는 작업 대기열이 비어있을 때 클라이언트가 이를 감지할 수 있는 좋은 방법을 제공하지
않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는
Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다.
대기열을 만들고, 메시지로 채운다. 각 메시지는 수행할 하나의 작업을 나타낸다. 이
예에서, 메시지는 긴 계산을 수행할 정수다.
대기열에서 작업을 수행하는 잡을 시작한다. 잡은 여러 파드를 시작한다. 각 파드는
메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
kubectl run -i --tty temp --image redis --command "/bin/sh"
Waiting for pod default/redis2-c7h78 to be running, status is Pending, pod ready: false
Hit enter forcommand prompt
이제 엔터 키를 누르고, redis CLI를 시작하고, 몇몇 작업 항목이 포함된 목록을 생성한다.
#!/usr/bin/env pythonimporttimeimportrediswq
host="redis"# Uncomment next two lines if you do not have Kube-DNS working.# import os# host = os.getenv("REDIS_SERVICE_HOST")
q = rediswq.RedisWQ(name="job2", host="redis")
print("Worker with sessionID: "+ q.sessionID())
print("Initial queue state: empty="+str(q.empty()))
whilenot q.empty():
item = q.lease(lease_secs=10, block=True, timeout=2)
if item isnot None:
itemstr = item.decode("utf-8")
print("Working on "+ itemstr)
time.sleep(10) # Put your actual work here instead of sleep.
q.complete(item)
else:
print("Waiting for work")
print("Queue empty, exiting")
사용자 자신의 경로로 gcr.io/myproject 를
변경하려면 잡 템플릿을 편집해야 한다.
이 예에서, 각 파드는 대기열의 여러 항목에 대해 작업한 다음 더 이상 항목이 없을 때 종료된다.
워커는 작업 대기열이 비어있을 때를 감지하고 잡 컨트롤러는 작업 대기열에 대해
알지 못하기 때문에, 작업이 완료되면 워커에게 신호를 보낸다.
워커는 성공적으로 종료하여 대기열이 비어 있음을 알린다. 따라서, 워커가 성공적으로
종료하자마자, 컨트롤러는 작업이 완료되었음을 인식하고, 파드가 곧 종료된다.
따라서, 잡 완료 횟수를 1로 설정했다. 잡 컨트롤러는 다른 파드도 완료될 때까지
기다린다.
잡 실행
이제 잡을 실행한다.
kubectl apply -f ./job.yaml
이제 조금 기다린 다음, 잡을 확인한다.
kubectl describe jobs/job-wq-2
Name: job-wq-2
Namespace: default
Selector: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
Labels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
job-name=job-wq-2
Annotations: <none>
Parallelism: 2
Completions: <unset>
Start Time: Mon, 11 Jan 2016 17:07:59 -0800
Pods Statuses: 1 Running / 0 Succeeded / 0 Failed
Pod Template:
Labels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
job-name=job-wq-2
Containers:
c:
Image: gcr.io/exampleproject/job-wq-2
Port:
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
33s 33s 1{job-controller } Normal SuccessfulCreate Created pod: job-wq-2-lglf8
kubectl logs pods/job-wq-2-7r7b2
Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f
Initial queue state: empty=False
Working on banana
Working on date
Working on lemon
보시다시피, 사용자의 파드 중 하나가 여러 작업 단위에서 작업했다.
대안
대기열 서비스를 실행하거나 작업 대기열을 사용하도록 컨테이너를 수정하는 것이 불편한 경우, 다른
잡 패턴
중 하나를 고려할 수 있다.
만약 실행할 백그라운드 처리 작업의 연속 스트림이 있는 경우,
ReplicaSet 이 있는 백그라운드 워커를 실행하는 것과,
https://github.com/resque/resque와 같은
백그라운드 처리 라이브러리를 실행하는 것이 좋다.
4.8 - 클러스터 내 어플리케이션 접근
클러스터의 애플리케이션에 접근하기 위해 로드 밸런싱, 포트 포워딩, 방화벽 설정 또는 DNS 구성을 설정한다.
4.8.1 - 웹 UI (대시보드)
대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다.
대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고,
컨테이너화 된 애플리케이션을 트러블슈팅할 수 있으며, 클러스터 리소스들을 관리할 수 있다.
대시보드를 통해 클러스터에서 동작 중인 애플리케이션의 정보를 볼 수 있고,
개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등)
생성하거나 수정할 수 있다.
예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나
또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다.
UI는 커맨드가 실행된 머신에서 오직 접근 가능하다. 상세 내용은 kubectl proxy --help 옵션을 확인한다.
참고: Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 인증서를 지원하지 않는다.
웰컴 뷰
초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다.
이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다.
게다가, 대시보드가 있는 클러스터에서 기본적으로 kube-system네임스페이스이 동작중인 시스템 애플리케이션을 볼 수 있다.
컨테이너화 된 애플리케이션 배포
대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다.
애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드할 수 있다.
시작하는 페이지의 상위 오른쪽 코너에 있는 CREATE 버튼을 클릭한다.
애플리케이션 세부 정보 지정
배포 마법사는 다음 정보를 제공한다.
앱 이름 (필수): 애플리케이션 이름.
레이블 이름은
배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
애플리케이션 이름은 선택된 쿠버네티스 네임스페이스 안에서 유일해야 한다.
소문자로 시작해야 하며, 소문자 또는 숫자로 끝나고,
소문자, 숫자 및 대쉬(-)만을 포함해야 한다. 24 문자만을 제한한다.
처음과 끝의 스페이스는 무시된다.
컨테이너 이미지 (필수):
레지스트리에 올라간 퍼블릭 도커 컨테이너 이미지
또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL.
컨테이너 이미지 사양은 콜론으로 끝난다.
파드의 수 (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수.
값은 양의 정수만 허용됩니다.
서비스 (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의
퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 서비스를
노출시키고 싶을 수 있다.
참고: 외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다.
클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다.
서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면,
두 개의 포트를 정의해야 한다.
서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다.
서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다.
서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
만약 필요하다면, 더 많은 세팅을 지정할 수 있는 자세한 옵션 보기 섹션에서 확장할 수 있다.
설명: 입력하는 텍스트값은 디플로이먼트에
어노테이션으로
추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
레이블: 애플리케이션에 사용되는 기본적인 레이블은
애플리케이션 이름과 버전이다.
릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를
생성할 때 추가적으로 정의할 수 있다.
네임스페이스: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다.
이러한 가상 클러스터들을 네임스페이스라고 부른다.
논리적으로 명명된 그룹으로 리소스들을 분할할 수 있다.
대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다.
네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다.
네임스페이스 이름은 숫자로만 구성할 수 없다.
만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다.
만약 생성에 실패하면, 첫 번째 네임스페이스가 선택된다.
이미지 풀(Pull) 시크릿:
특정 도커 컨테이너 이미지가 프라이빗한 경우,
풀(Pull) 시크릿 자격 증명을 요구한다.
대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성할 수 있도록 한다.
시크릿 이름은 예를 들어 new.image-pull.secret 과 같이 DNS 도메인 이름 구문으로 따르기로 한다.
시크릿 내용은 base64 인코딩 방식이며,
.dockercfg 파일로 정의된다.
시크릿 이름은 최대 253 문자를 포함할 수 있다.
이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다.
CPU 요구 사항 (cores) 와 메모리 요구 사항 (MiB):
컨테이너를 위한 최소 리소스 상한을
정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
커맨드 실행 와 커맨드 인수 실행:
기본적으로, 컨테이너는 선택된 도커 이미지의
기본 엔트리포인트 커맨드를 실행한다.
커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
특권을 가진(privileged) 상태로 실행: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이
특권을 가진 컨테이너의
프로세스들과 동등한지 아닌지 정의한다.
특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
환경 변수: 쿠버네티스 서비스를
환경 변수를 통해 노출한다.
환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다.
애플리케이션들이 서비스를 찾는데 사용된다.
값들은 $(VAR_NAME) 구문을 사용하는 다른 변수들로 참조할 수 있다.
YAML 또는 JSON 파일 업로드
쿠버네티스는 선언적인 설정을 제공한다.
이 방식으로 모든 설정은 쿠버네티스 API 리소스 스키마를
이용하여 YAML 또는 JSON 설정 파일에 저장한다.
배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신,
애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
대시보드 사용
다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다.
탐색
클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다.
기본적으로 기본 네임스페이스의 오프젝트만이 보이는데,
이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다.
어드민 개요
클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다.
노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다.
세부사항은 각 노드들에 대한 사용량, 사양, 상태,
할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
워크로드
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다.
애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고
각각의 워크로드 종류는 따로 보여진다.
리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은
워크로드에 대한 실용적인 정보를 요약한다.
워크로드에 대한 세부적인 것들은 상태와 사양 정보,
오프젝트들 간의 관계를 보여준다.
예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
서비스
외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는
쿠버네티스 리소스들을 보여준다.
이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과
외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
스토리지
스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.
컨피그 맵과 시크릿
클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다.
컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.
로그 뷰어
파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다.
뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다.
최초로 쿠버네티스 API에 접근할 때 우리는
쿠버네티스 CLI인 kubectl을 사용하는 것을 추천한다.
클러스터에 접근하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
인증정보를 가져야 한다. 일반적으로 이는 당신이
Getting started guide를 다 진행했을 때 자동으로 구성되거나,
다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다.
kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확인한다.
kubectl config view
여기에서
kubectl 사용 예시를 볼 수 있으며, 완전한 문서는
kubectl 매뉴얼에서 확인할 수 있다.
REST API에 직접 접근
kubectl은 apiserver의 위치 파악과 인증을 처리한다.
만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로
REST API에 직접 접근하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다.
kubectl을 proxy 모드로 실행.
권장하는 접근 방식.
저장된 apiserver 위치를 사용.
self-signed 인증서를 사용하여 apiserver의 identity를 검증. MITM은 불가능.
apiserver 인증.
앞으로는 클라이언트 측의 지능형 load balancing과 failover가 될 것이다.
직접적으로 http 클라이언트에 위치정보와 인증정보를 제공.
대안적인 접근 방식.
proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 코드와 같이 동작한다.
MITM로부터 보호를 위해 root 인증서를 당신의 브라우저에 저장해야 한다.
kubectl proxy 사용
다음 커맨드는 kubectl을 리버스 프록시(reverse proxy)처럼 동작하는 모드를 실행한다. 이는
apiserver의 위치지정과 인증을 처리한다.
다음과 같이 실행한다.
위 예제에서는 --insecure flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로
두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을
서버 접속에 사용한다.
(이들은 ~/.kube 디렉터리에 설치된다.)
일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가
root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다.
localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을
요구하지 않지만 이는 표준이 아니다.
API에 대한 접근 제어은
클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 import "k8s.io/client-go/kubernetes"로 import하는 것을 예로 들 수 있다.
Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 kubeconfig file을 사용할 수 있다.
예제를 참고한다.
Python 클라이언트를 사용하려면 pip install kubernetes 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 Python Client Library page를 참조한다.
Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 kubeconfig file을 사용할 수 있다.
예제를 참조한다.
다른 언어
다른 언어에서 API를 접속하기 위한 클라이언트 라이브러리들도 존재한다.
이들이 어떻게 인증하는지는 다른 라이브러리들의 문서를 참조한다.
파드에서 API 접근
파드에서 API를 접속한다면 apiserver의
위치지정과 인증은 다소 다르다.
파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은
kubernetes.default.svc DNS 네임을 사용하는 것이다.
이 DNS 네임은 apiserver로 라우팅되는 서비스 IP로 resolve된다.
apiserver 인증에 추천되는 방식은
서비스 어카운트
인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며
해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의
/var/run/secrets/kubernetes.io/serviceaccount/token에 위치한다.
사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt에 위치하며
apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의
/var/run/secrets/kubernetes.io/serviceaccount/namespace 파일로 존재한다.
파드 내에서 API에 접근하는데 권장되는 방식은 다음과 같다.
파드의 sidecar 컨테이너 내에서 kubectl proxy를 실행하거나,
컨테이너 내부에서 백그라운드 프로세스로 실행한다.
이는 쿠버네티스 API를 파드의 localhost 인터페이스로 프록시하여
해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다.
Go 클라이언트 라이브러리를 이용하여 rest.InClusterConfig()와 kubernetes.NewForConfig() 함수들을 사용하도록 클라이언트를 만든다.
이는 apiserver의 위치지정과 인증을 처리한다. 예제
각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다.
클러스터에서 실행되는 서비스로 접근
이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다.
쿠버네티스에서, 노드,
파드 및 서비스는 모두
고유한 IP를 가진다. 사용자의 데스크탑 PC와 같은 클러스터 외부 장비에서는
클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 접근을
할 수 없을 것이다.
통신을 위한 방식들
클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다.
공인 IP를 통해 서비스에 접근.
클러스터 외부에서 접근할 수 있도록 NodePort 또는 LoadBalancer 타입의
서비스를 사용한다. 서비스와
kubectl expose 문서를 참조한다.
클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며,
인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
해당 서비스는 자체적으로 인증을 수행하는가?
파드는 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 디버깅 같은 목적으로 접근하려면
해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택하는 신규 서비스를 생성한다.
대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
접근할 필요는 없다.
Proxy Verb를 사용하여 서비스, 노드, 파드에 접근.
원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 포트에
접근을 하려고 하거나 디버깅을 하려면 이를 사용한다.
파드를 실행한 다음, kubectl exec를 사용하여 해당 파드의 셸로 접속한다.
해당 셸에서 다른 노드, 파드, 서비스에 연결한다.
어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다.
빌트인 서비스 검색
일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다.
kubectl cluster-info 커맨드로 이 서비스의 리스트를 볼 수 있다.
kubectl cluster-info
결괏값은 다음과 같을 것이다.
Kubernetes master is running at https://104.197.5.247
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다.
예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여
https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/로 접근할 수 있다. 예를 들어 kubectl proxy로
http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/를 통해 logging에 접근할 수도 있다.
(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 쿠버네티스 API를 사용해서 클러스터에 접근하기을 참조한다.)
수작업으로 apiserver 프록시 URL을 구축
위에서 언급한 것처럼 서비스의 프록시 URL을 검색하는 데 kubectl cluster-info 커맨드를 사용할 수 있다. 서비스 엔드포인트, 접미사, 파라미터를 포함하는 프록시 URL을 생성하려면 해당 서비스에
http://kubernetes_master_address/api/v1/namespaces/namespace_name/services/service_name[:port_name]/proxy 형식의 프록시 URL을 덧붙인다.
당신이 포트에 이름을 지정하지 않았다면 URL에 port_name 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, port_name 이 들어갈 자리에 포트 번호를 기재할 수도 있다.
기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 https:를 붙인다.
http://kubernetes_master_address/api/v1/namespaces/namespace_name/services/https:service_name:[port_name]/proxy
URL의 네임 부분에 지원되는 양식은 다음과 같다.
<service_name> - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다.
<service_name>:<port_name> - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
https:<service_name>: - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론(:)에 주의)
https:<service_name>:<port_name> - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
예제들
Elasticsearch 서비스 endpoint _search?q=user:kimchy에 접근하려면 http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy를 사용할 수 있다.
Elasticsearch 클러스터 상태 정보 _cluster/health?pretty=true에 접근하려면 https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true를 사용할 수 있다.
웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만,
당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다.
몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을
구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다.
요청 redirect
redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다.
kubectl이 설치되었는지 확인하려면,
kubectl version --client을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
마이너 버전 하나 차이 이내여야
한다.
클러스터, 사용자, 컨텍스트 정의
당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자.
development 클러스터에서는 프런트 엔드 개발자들이 frontend라는 네임스페이스에서
작업을 하고 있고, 스토리지 개발자들은 storage라는 네임스페이스에서 작업을 하고 있다.
scratch 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조
네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고,
scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다.
config-exercise라는 디렉터리를 생성한다. config-exercise 디렉터리에
다음 내용을 가진 config-demo라는 파일을 생성한다.
위 fake-ca-file, fake-cert-file, fake-key-file은 인증서 파일들의 실제 경로 이름을 위한
플레이스홀더(placeholder)이다.
당신의 환경에 맞게 이들을 실제 인증서 경로로 변경해줘야 한다.
만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면
이 경우 키에 -data 접미사를 추가해야 한다. 예를 들면 certificate-authority-data,
client-certificate-data, client-key-data 같이 사용할 수 있다.
컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어
dev-frontend 컨텍스트는 "development 클러스터의 frontend 네임스페이스에 접근하는데
developer 사용자 자격증명을 사용하라고 알려준다."
당신의 KUBECONFIG 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로
표시될 것이다. 특히, 합쳐진 정보가 config-demo-2 파일의 dev-ramp-up
컨텍스트와 config-demo 파일의 세 개의 컨텍스트들을
가지고 있다는 것에 주목하길 바란다.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mongo ClusterIP 10.96.41.183 <none> 27017/TCP 11s
MongoDB 서버가 파드 안에서 실행되고 있고, 27017번 포트에서 수신하고 있는지 확인한다.
# mongo-75f59d57f4-4nd6q 를 사용자의 파드 이름으로 대체한다.
kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
출력은 파드 내 MongoDB 포트 번호를 보여준다.
27017
(이는 인터넷 상의 MongoDB에 할당된 TCP 포트이다.)
파드의 포트를 로컬 포트로 포워딩하기
`kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
# mongo-75f59d57f4-4nd6q 를 사용자의 파드 이름으로 대체한다.
kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
서비스의 노드포트(NodePort) 값을 메모하자. 예를 들어,
앞선 결과에서, 노드포트 값은 31496이다.
Hello World 애플리케이션이 실행 중인 파드를 나열한다.
kubectl get pods --selector="run=load-balancer-example" --output=wide
결과는 아래와 같다.
NAME READY STATUS ... IP NODE
hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1
hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2
Hello World 파드가 실행 중인 노드들 중 하나의 노드에 대해 공용
IP 주소를 얻자. 이 주소를 얻는 방법은 어떻게 클러스터를 설치했는지에
따라 다르다. 예를 들어, Minikube를 사용하면, kubectl cluster-info를
실행하여 노드 주소를 알 수 있다. Google Compute Engine 인스턴스를
사용하면, gcloud compute instances list 명령어를
사용하여 노드들의 공용 주소를 알 수
있다.
선택한 노드에서 노드 포트에 대해 TCP 통신을 허용하도록 방화벽 규칙을
생성하자. 예를 들어, 서비스의 노드포트 값이 31568인 경우,
31568 포트로 TCP 통신을 허용하도록 방화벽 규칙을 생성하자. 다른
클라우드 공급자는 방화벽 규칙을 설정하는 다른 방법을 제공한다.
Hello World 애플리케이션 접근을 위해 노드 주소와 노드 포트를 사용하자.
curl http://<public-node-ip>:<node-port>
<public-node-ip>는 노드의 공용 IP 주소이고,
<node-port>는 서비스의 노드포트 값이다.
성공적인 요청에 대한 응답은 hello 메시지이다.
Hello Kubernetes!
서비스 설정 파일 사용하기
kubectl expose를 사용하는 대신,
서비스 설정 파일을 사용해
서비스를 생성할 수 있다.
정리하기
서비스를 삭제하기 위해 다음 명령어를 입력하자.
kubectl delete services example-service
디플로이먼트, 레플리카셋, Hello World 애플리케이션이 실행 중인 파드를
삭제하기 위해 다음 명령어를 입력하자.
# The identifier Backend is internal to nginx, and used to name this specific upstream
upstream Backend {
# hello is the internal DNS name used by the backend Service inside Kubernetes
server hello;
}
server {
listen 80;
location / {
# The following statement will proxy traffic to the upstream named Backend
proxy_pass http://Backend;
}
}
백엔드와 같이, 프론트엔드는 디플로이먼트와 서비스를 갖고 있다. 백엔드
서비스와 프론트엔드 서비스 간에 주목해야 할 중요한 차이점은 프론트엔드
서비스의 구성에 type: LoadBalancer 가 있다는 것이다. 즉,
서비스가 클라우드 공급자가 프로비저닝한 로드 밸런서를 사용하고
클러스터 외부에서 접근할 수 있음을 의미한다.
첫 번째 컨테이너에는 nginx 웹 서버를 실행하는 구성 파일이 나열되어 있다.
공유 볼륨의 마운트 경로는 /usr/share/nginx/html이다.
두 번째 컨테이너는 debian 이미지 기반이고, 마운트 경로는 /pod-data이다.
두 번째 컨테이너는 다음 명령어를 실행한 후에 종료한다.
echo debian 컨테이너에서 안녕하세요 > /pod-data/index.html
두 번째 컨테이너는 index.html 파일을
nginx 웹 서버에서 호스팅하는 문서의 루트 디렉터리(/usr/share/nginx/html/)에 저장한다.
USER PID ... STAT START TIME COMMAND
root 1 ... Ss 21:12 0:00 nginx: master process nginx -g daemon off;
Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 디렉터리에 index.html 파일을 생성했었음을 상기하자.
curl을 이용하여 nginx 웹 서버에 HTTP GET 요청을 보낸다.
root@two-containers:/# curl localhost
출력을 보면, nginx 웹 서버에서 debian 컨테이너에서 쓰여진 웹 페이지를 제공하는 것을 알 수 있다.
debian 컨테이너에서 안녕하세요
토의
파드가 여러 컨테이너를 가질 수 있는 주요 이유는 기본 애플리케이션을 보조할
도우미(helper) 애플리케이션을 제공하기 위해서이다. 도우미 애플리케이션의 일반적인 예로는
데이터를 가지고 오는 경우(data puller)나 데이터를 보내주는 경우(data pusher)이거나 프록시가 있다.
도우미와 기본 애플리케이션은 종종 서로 간에 통신을 해야 할 수 있다.
일반적으로 이는 이번 예제에서 살펴본 것 같이, 공유 파일 시스템을 통하거나,
루프백 네트워크 인터페이스 곧 로컬 호스트(localhost)를 통해서 이뤄진다. 이 패턴의 한가지 예는
웹 서버가 도우미 프로그램과 함께 Git 저장소에서 새 업데이트를 받아오는 경우이다.
이 예제에서 볼륨은 파드의 생명 주기 동안 컨테이너를 위한 통신 방법으로 이용했다.
파드가 삭제되고 재생성되면, 공유 볼륨에 저장된 데이터는 잃어버린다.
모니터링 및 로깅을 설정하여 클러스터 문제를 해결하거나, 컨테이너화된 애플리케이션을 디버깅한다.
4.9.1 - 리소스 메트릭 파이프라인
컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은
쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은
kubectl top 커맨드 사용하여 사용자가 직접적으로 액세스하거나,
Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
메트릭 API
메트릭 API를 통해, 주어진 노드나 파드에서 현재 사용중인
리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지
않으므로, 예를 들어, 지정된 노드에서 10분 전에 사용된 리소스의 양을
가져오는 것과 같은 일을 할 수는 없다.
이 API와 다른 API는 차이가 없다.
다른 쿠버네티스 API의 엔드포인트와 같이 /apis/metrics.k8s.io/ 하위 경로에서 발견될 수 있다
동일한 보안, 확장성 및 신뢰성 보장을 제공한다
k8s.io/metrics
리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다.
참고: 이 API를 사용하려면 메트릭 서버를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다.
리소스 사용량 측정
CPU
CPU는 일정 기간 동안
CPU 코어에서
평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는
누적 CPU 카운터보다 높은 비율을 적용해서 얻는다.
kubelet은 비율 계산에 사용할 윈도우를 선택한다.
메모리
메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다.
이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다.
그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다.
쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다.
호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다.
메트릭 서버
메트릭 서버는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
kube-up.sh 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가
디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
디플로이먼트 components.yaml 파일을 사용하여 메트릭 서버를 배포할 수 있다.
메트릭 서버는 각 노드에서 Kubelet에 의해
노출된 Summary API에서 메트릭을 수집하고, 쿠버네티스 aggregator를
통해 메인 API 서버에 등록된다.
애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면,
애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다.
컨테이너, 파드,
서비스,
그리고 전체 클러스터의 특성을 검사하여
쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서
애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다.
이 정보는 애플리케이션의 성능을 평가하고
병목 현상을 제거하여 전체 성능을 향상할 수 있게 해준다.
쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다.
신규 클러스터에서는, 리소스 메트릭 또는
완전한 메트릭 파이프라인으로 모니터링 통계를 수집할 수 있다.
리소스 메트릭 파이프라인
리소스 메트릭 파이프라인은
Horizontal Pod Autoscaler
컨트롤러와 같은 클러스터 구성요소나
kubectl top 유틸리티에 관련되어 있는
메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인
metrics-server에
의해서 수집되며 metrics.k8s.io API를 통해 노출된다.
metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의
Kubelet에 CPU와 메모리
사용량을 질의한다. Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 해서
머신에서 구동되는 파드와 컨테이너를 관리한다. Kubelet은 각각의 파드를 해당하는
컨테이너로 변환하고 컨테이너 런타임 인터페이스를 통해서 컨테이너 런타임에서
개별 컨테이너의 사용량 통계를 가져온다. Kubelet은 이 정보를 레거시 도커와의
통합을 위해 kubelet에 통합된 cAdvisor를 통해 가져온다. 그 다음으로 취합된 파드
리소스 사용량 통계를 metric-server 리소스 메트릭 API를 통해 노출한다. 이 API는
kubelet의 인증이 필요한 읽기 전용 포트 상의 /metrics/resource/v1beta1에서
제공된다.
완전한 메트릭 파이프라인
완전한 메트릭 파이프라인은 보다 풍부한 메트릭에 접근할 수 있도록 해준다.
쿠버네티스는 Horizontal Pod Autoscaler와 같은 메커니즘을 활용해서 이런 메트릭에
대한 반응으로 클러스터의 현재 상태를 기반으로 자동으로 스케일링하거나 클러스터를
조정할 수 있다. 모니터링 파이프라인은 kubelet에서 메트릭을 가져와서 쿠버네티스에
custom.metrics.k8s.io와 external.metrics.k8s.io API를 구현한 어댑터를 통해
노출한다.
CNCF 프로젝트인, 프로메테우스는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다.
CNCF 프로젝트가 아닌 완전한 메트릭 파이프라인 프로젝트는 쿠버네티스 문서의 범위가 아니다.
4.9.3 - 초기화 컨테이너(Init Containers) 디버그하기
이 페이지는 초기화 컨테이너의 실행과 관련된 문제를
조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 <pod-name> 으로,
초기화 컨테이너를 <init-container-1> 과
<init-container-2> 로 표시한다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
kubectl apply -f https://k8s.io/examples/debug/termination.yaml
YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에
"Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는
것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를
기록한 후에 종료된다.
파드와 관련된 정보를 출력한다.
kubectl get pod termination-demo
파드가 더 이상 실행되지 않을 때까지 앞선 명령어를 반복한다.
파드에 관한 상세 정보를 출력한다.
kubectl get pod termination-demo --output=yaml
결과는 "Sleep expired" 메시지를 포함한다.
apiVersion: v1
kind: Pod
...
lastState:
terminated:
containerID: ...
exitCode: 0
finishedAt: ...
message: |
Sleep expired
...
종료 메시지만을 포함하는 출력 결과를 보기
위해서는 Go 템플릿을 사용한다.
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
종료 메시지 사용자 정의하기
쿠버네티스는 컨테이너의 terminationMessagePath 필드에 지정된
종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은
/dev/termination-log 이다. 이 필드를 사용자 정의 함으로써
쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다.
쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다.
종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다.
kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는
12KiB로 제한된다. 기본 종료 메시지 경로는 /dev/termination-log이다.
파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다.
다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록
/tmp/my-log 파일에 종료 메시지를 기록한다.
또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 terminationMessagePolicy
필드를 설정할 수 있다. 이 필드의 기본 값은 File 이며,
이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다.
terminationMessagePolicy 필드의 값을 "FallbackToLogsOnError 으로
설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우
쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다.
로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다.
파드 디버깅의 첫 번째 단계는 파드를 살펴 보는 것이다. 다음의 명령어를
사용하여 파드의 현재 상태와 최근 이벤트를 점검한다.
kubectl describe pods ${POD_NAME}
파드 내부 컨테이너의 상태를 확인한다. 모두 Running 상태인가?
최근에 재시작 되었는가?
파드의 상태에 따라 디버깅을 계속한다.
파드가 pending 상태로 유지
파드가 Pending 상태로 멈춰 있는 경우는, 노드에 스케줄 될 수 없음을 의미한다.
일반적으로 이것은 어떤 유형의 리소스가 부족하거나 스케줄링을 방해하는 다른 요인 때문이다.
상단의 kubectl describe ... 명령의 결과를 확인하자.
파드를 스케줄 할 수 없는 이유에 대한 스케줄러의 메세지가 있어야 한다.
이유는 다음과 같다.
부족한 리소스
사용자 클러스터의 CPU 나 Memory의 공급이 소진되었을 수 있다. 이 경우
몇 가지 방법을 시도할 수 있다.
리소스 쿼터
기능은 사용할 수 있는 전체 리소스의 양을 제한하도록 설정할 수 있다.
네임스페이스와 함께 사용하면,
한 팀이 모든 리소스를 점유하는 것을 방지할 수 있다.
hostPort 사용하기
파드를 hostPort 에 바인딩 할 때 파드를 스케줄링 할 수 있는
위치는 제한되어 있다. 대부분의 경우 hostPort 는 불필요하다. 서비스 오브젝트를
사용하여 파드를 노출하도록 한다. hostPort 가 필요한 경우
컨테이너 클러스터에 있는 노드의 수만큼 파드를 스케줄 할 수 있다.
파드가 waiting 상태로 유지
파드가 Waiting 상태에서 멈춘 경우, 워커 노드에 스케줄 되었지만, 해당 장비에서 사용할 수 없다.
거듭 강조하지만, kubectl describe ... 의 정보는 유익하게 사용되어야 한다.
Waiting 파드의 가장 일반적인 원인은 이미지를 가져오지 못하는 경우이다.
확인해야 할 3가지 사항이 있다.
이미지 이름이 올바른지 확인한다.
이미지를 저장소에 푸시하였는가?
이미지가 풀 될 수 있는지 보기 위해, 사용자의 장비에서 docker pull <image> 를 수동으로
실행한다.
파드가 손상(crashing)되었거나 양호하지 않을(unhealthy) 경우
일단 사용자의 파드가 스케줄 되면, 구동중인 파드 디버그하기에
기술된 메서드를 디버깅에 사용할 수 있다.
레플리케이션컨트롤러 디버깅
레플리케이션컨트롤러는 매우 간단하다. 이 오브젝트는 파드를 만들거나
만들 수 없는 경우뿐이다. 만약 파드를 만들 수 없는 경우,
위의 지침을 참조하여 파드를 디버그한다.
사용자는 kubectl describe rc ${CONTROLLER_NAME} 을 사용하여 레플리케이션 컨트롤러와
관련된 이벤트를 검사할 수도 있다.
4.10 - 쿠버네티스 확장
쿠버네티스 클러스터를 작업 환경의 요구에 맞게 조정하는 고급 과정을 이해한다.
4.10.1 - 확장 API 서버 설정
애그리게이션 레이어(aggregation layer)와 작동하도록 확장 API 서버를 설정하면 쿠버네티스 API 서버를 쿠버네티스의 핵심 API의 일부가 아닌 추가 API로 확장할 수 있다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
다음 단계는 확장 API 서버를 높은 수준 으로 설정하는 방법을 설명한다. 이 단계는 YAML 구성을 사용하거나 API를 사용하는 것에 상관없이 적용된다. 둘 사이의 차이점을 구체적으로 식별하려고 시도한다. YAML 구성을 사용하여 구현하는 방법에 대한 구체적인 예를 보려면, 쿠버네티스 리포지터리에서 sample-apiserver를 참고할 수 있다.
또는, apiserver-builder와 같은 기존의 타사 솔루션을 사용하여 스켈레톤(skeleton)을 생성하고 다음 단계를 모두 자동화해야 한다.
API서비스(APIService) API가 활성화되어 있는지 확인한다(--runtime-config 확인). 클러스터에서 일부러 해제하지 않았다면, 기본적으로 활성화되어 있어야 한다.
API서비스 오브젝트를 추가하거나 클러스터 관리자가 작성하도록 RBAC 규칙을 작성해야 할 수도 있다. (API 확장은 전체 클러스터에 영향을 주기 때문에, 운영 중인 클러스터에서 API 확장에 대한 테스트/개발/디버깅을 수행하지 않는 것이 좋다.)
확장 API 서비스를 실행하려는 쿠버네티스 네임스페이스를 생성한다.
HTTPS를 위해 확장 API 서버가 사용하는 서버 인증서에 서명하는 데 사용할 CA 인증서를 생성하거나 가져온다.
HTTPS를 위해 API 서버가 사용할 서버 인증서/키를 생성한다. 이 인증서는 위의 CA 인증서에 의해 서명해야 한다. 또한 Kube DNS 이름의 CN이 있어야 한다. 이것은 쿠버네티스 서비스에서 파생되었으며 <service name>.<service name namespace>.svc 형식이다.
네임스페이스에 서버 인증서/키를 사용하여 쿠버네티스 시크릿을 생성한다.
확장 API 서버에 대한 쿠버네티스 디플로이먼트를 생성하고 시크릿을 볼륨으로 로드하는지 확인한다. 확장 API 서버의 작동하는(working) 이미지에 대한 참조를 포함해야 한다. 디플로이먼트는 네임스페이스에도 있어야 한다.
확장 API 서버가 해당 볼륨에서 해당 인증서를 로드하고 HTTPS 핸드셰이크에 사용되는지 확인한다.
네임스페이스에서 쿠버네티스 서비스 어카운트를 생성한다.
리소스에 허용하려는 작업에 대한 쿠버네티스 클러스터 롤(role)을 생성한다.
네임스페이스의 서비스 어카운트에서 방금 만든 클러스터 롤로 쿠버네티스 클러스터 롤 바인딩을 생성한다.
네임스페이스의 서비스 어카운트에서 system:auth-delegator 클러스터 롤로 쿠버네티스 클러스터 롤 바인딩을 만들어 인증 결정을 쿠버네티스 핵심 API 서버에 위임한다.
네임스페이스의 서비스 어카운트에서 extension-apiserver-authentication-reader 롤로 쿠버네티스 롤 바인딩을 생성한다. 이를 통해 확장 API 서버가 extension-apiserver-authentication 컨피그맵(configmap)에 접근할 수 있다.
쿠버네티스 API 서비스를 생성한다. 위의 CA 인증서는 base64로 인코딩되어, 새로운 라인이 제거되고 API 서비스에서 spec.caBundle로 사용되어야 한다. 이것은 namespaced가 아니어야 한다. kube-aggregator API를 사용하는 경우, base64 인코딩이 수행되므로 PEM 인코딩된 CA 번들만 통과한다.
kubectl을 사용하여 리소스를 얻는다. kubectl을 실행하면, "No resources found."가 반환된다. 이 메시지는
모든 것이 작동됐지만 현재 해당 리소스 유형의 오브젝트가 생성되지 않았음을 나타낸다.
TLS(Transport Layer Security)를 사용하여 클러스터 내 트래픽을 보호하는 방법을 이해한다.
4.11.1 - Kubelet의 인증서 갱신 구성
이 페이지는 kubelet에 대한 인증서 갱신을 활성화하고 구성하는 방법을 보여준다.
FEATURE STATE:Kubernetes v1.19 [stable]
시작하기 전에
쿠버네티스 1.8.0 버전 혹은 그 이상의 버전이 요구됨
개요
kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다.
기본적으로 이러한 인증서는 1년 만기로 발급되므로
너무 자주 갱신할 필요는 없다.
쿠버네티스 1.8은 kubelet 인증서
갱신을 포함하며,
이 기능은 현재 인증서의 만료 시한이 임박한 경우,
새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 베타 기능이다.
새로운 인증서를 사용할 수 있게 되면
쿠버네티스 API에 대한 연결을 인증하는데 사용된다.
클라이언트 인증서 갱신 활성화하기
kubelet 프로세스는 현재 사용 중인 인증서의 만료 시한이 다가옴에 따라
kubelet이 자동으로 새 인증서를 요청할지 여부를 제어하는
--rotate-certificates 인자를 허용한다.
kube-controller-manager 프로세스는 얼마나 오랜 기간 인증서가 유효한지를 제어하는
--cluster-signing-duration (1.19 이전은 --experimental-cluster-signing-duration)
인자를 허용한다.
인증서 갱신 구성에 대한 이해
kubelet이 시작할 때 부트 스트랩 (--bootstrap-kubeconfig 플래그를 사용)
을 구성하면 초기 인증서를 사용하여 쿠버네티스 API에 연결하고
인증서 서명 요청을 발행한다.
다음을 사용하여 인증서 서명 요청 상태를 볼 수 있다.
kubectl get csr
초기에 노드의 kubelet에서 인증서 서명 요청은 Pending 상태이다.
인증서 서명 요청이 특정 기준을 충족하면 컨트롤러 관리자가
자동으로 승인한 후 상태가 Approved 가 된다.
다음으로, 컨트롤러 관리자는
--cluster-signing-duration 파라미터에 의해 지정된 기간 동안
발행된 인증서에 서명하고
서명된 인증서는 인증서 서명 요청에 첨부된다.
kubelet은 쿠버네티스 API로 서명된 인증서를 가져와서
--cert-dir에 지정된 위치에 디스크에 기록한다.
그런 다음 kubelet은 쿠버네티스 API에 연결해서 새로운 인증서를 사용한다.
서명된 인증서의 만료가 다가오면 kubelet은 쿠버네티스 API를 사용하여
새로운 인증서 서명 요청을 자동으로 발행한다.
이는 인증서 유효 기간이 30%-10% 남은 시점에 언제든지 실행될 수 있다.
또한, 컨트롤러 관리자는 인증서 요청을 자동으로 승인하고
서명된 인증서를 인증서 서명 요청에 첨부한다.
kubelet은 쿠버네티스 API로 서명된 새로운 인증서를 가져와서 디스크에 쓴다.
그런 다음 새로운 인증서를 사용한 재연결을 위해서
가지고 있는 쿠버네티스 API로의 연결을 업데이트 한다.
4.11.2 - 클러스터에서 TLS 인증서 관리
쿠버네티스는 사용자가 제어하는 인증 기관 (CA)에서 서명한 TLS 인증서를
프로비저닝 할 수 있는 certificates.k8s.io API를 제공한다.
이러한 CA 및 인증서는 워크로드 간의 신뢰 관계를 구성하는 용도로 사용할 수 있다.
참고:certificates.k8s.io API를 사용하여 생성된 인증서는 전용 CA로 서명된다.
이러한 목적을 위해 클러스터 루트 CA를 사용하도록 클러스터를
구성할 수 있지만, 절대 이에 의존해서는 안된다.
해당 인증서가 클러스터 루트 CA에 대해 유효성을 검사한다고 가정하면 안된다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
파드로 실행되는 애플리케이션에서 사용자 정의 CA를 신뢰하려면
일반적으로 몇 가지 추가 애플리케이션 구성이 필요하다.
TLS 클라이언트 또는 서버가 신뢰하는 CA 인증서 목록에
CA 인증서 번들을 추가해야 한다.
예를 들어 인증서 체인을 파싱하고, 파싱된 인증서를 tls.Config 구조체의
RootCAs 필드에 추가하여, golang TLS 구성으로 이를 수행할 수 있다.
여기서 192.0.2.24는 서비스의 클러스터 IP,
my-svc.my-namespace.svc.cluster.local은 서비스의 DNS 이름,
10.0.34.2는 파드의 IP,my-pod.my- namespace.pod.cluster.local은
파드의 DNS 이름이다. 다음 출력이 표시되어야 한다.
1단계에서 만든 server.csr 파일은 base64로 인코딩되고
.spec.request 필드에 숨겨져 있다.
또한 kubernetes.io/kubelet-serving 서명자가 서명한
"digitalSignature", "keyEnciperment" 및 "serverAuth" 키 사용(keyUsage)이 있는 인증서를 요청한다.
특정 signerName을 요청해야 한다.
자세한 내용은 지원되는 서명자 이름
문서를 참조한다.
이제 CSR이 API에서 보류 상태로 표시되어야 한다. 다음을 실행하여
확인할 수 있다.
kubectl describe csr my-svc.my-namespace
Name: my-svc.my-namespace
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 21 Mar 2017 07:03:51 -0700
Requesting User: yourname@example.com
Status: Pending
Subject:
Common Name: my-svc.my-namespace.svc.cluster.local
Serial Number:
Subject Alternative Names:
DNS Names: my-svc.my-namespace.svc.cluster.local
IP Addresses: 192.0.2.24
10.0.34.2
Events: <none>
인증서 서명 요청 승인 받기
인증서 서명 요청을 승인하는 것은 자동화된 승인 프로세스나
클러스터 관리자에 의해 일회성으로 수행한다. 여기에
관련된 내용에 대한 자세한 내용은 아래에서 설명한다.
인증서 다운로드 및 사용
CSR이 서명되고 승인되면 다음이 표시된다.
kubectl get csr
NAME AGE REQUESTOR CONDITION
my-svc.my-namespace 10m yourname@example.com Approved,Issued
이제 server.crt 및 server-key.pem을 키페어(keypair)로 사용하여
HTTPS 서버를 시작할 수 있다.
인증서 서명 요청 승인
(적절한 권한이 있는) 쿠버네티스 관리자는
kubectl certificate approve 과 kubectl certificate deny
명령을 사용하여 인증서 서명 요청을 수동으로 승인 (또는 거부) 할 수 있다.
그러나 이 API를 많이 사용한다면,
자동화된 인증서 컨트롤러 작성을 고려할 수 있다.
위와 같이 kubectl을 사용하는 시스템이든 사람이든, 승인자의 역할은
CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다.
CSR은 CSR에 서명하는 데 사용되는 개인 키를 제어하는 것이다. 이는
승인된 대상으로 가장하는 제 3자의 위협을 해결한다. 위의 예에서
이 단계는 파드(pod)가 CSR을 생성하는 데
사용되는 개인 키를 제어하는지 확인하는 것이다.
CSR은 요청된 상황에서 작동할 권한이 있다. 이것은
원하지 않는 대상이 클러스터에 합류(join)하는 위협을
해결한다. 위의 예에서, 이 단계는
파드가 요청된 서비스에 참여할 수 있는지 확인하는 것이다.
이 두 가지 요구 사항이 충족되는 경우에만, 승인자가 CSR을 승인하고
그렇지 않으면 CSR을 거부해야 한다.
승인 허가에 대한 경고문
CSR을 승인하는 능력은 환경 내에서 누구를 신뢰하는지 결정한다. CSR 승인
능력은 광범위하거나 가볍게 부여해서는 안된다. 이 권한을
부여하기 전에 이전 섹션에서 언급한
요청의 요구 사항과 특정 인증서 발급의 영향을
완전히 이해해야 한다.
클러스터 관리자를 위한 참고 사항
이 가이드에서는 서명자가 인증서 API를 제공하도록 설정되었다고 가정한다. 쿠버네티스
컨트롤러 관리자는 서명자의 기본 구현을 제공한다. 이를
활성화하려면 인증 기관(CA)의 키 쌍에 대한 경로와 함께 --cluster-signing-cert-file 와
--cluster-signing-key-file 매개 변수를
컨트롤러 관리자에 전달한다.
4.12 - 클러스터 데몬 관리
롤링 업데이트 수행과 같은 데몬셋 관리를 위한 일반적인 작업을 수행한다.
4.12.1 - 데몬셋(DaemonSet)에서 롤링 업데이트 수행
이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다.
시작하기 전에
데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다.
데몬셋 업데이트 전략
데몬셋에는 두 가지 업데이트 전략 유형이 있다.
OnDelete: OnDelete 업데이트 전략을 사용하여, 데몬셋 템플릿을 업데이트한 후,
이전 데몬셋 파드를 수동으로 삭제할 때 만 새 데몬셋 파드가
생성된다. 이것은 쿠버네티스 버전 1.5 이하에서의 데몬셋의 동작과
동일하다.
RollingUpdate: 기본 업데이트 전략이다.
RollingUpdate 업데이트 전략을 사용하여, 데몬셋 템플릿을
업데이트한 후, 오래된 데몬셋 파드가 종료되고, 새로운 데몬셋 파드는
제어 방식으로 자동 생성된다. 전체 업데이트 프로세스 동안 데몬셋의 최대 하나의 파드가 각 노드에서 실행된다.
롤링 업데이트 수행
데몬셋의 롤링 업데이트 기능을 사용하려면,
.spec.updateStrategy.type 에 RollingUpdate 를 설정해야 한다.
apiVersion:apps/v1kind:DaemonSetmetadata:name:fluentd-elasticsearchnamespace:kube-systemlabels:k8s-app:fluentd-loggingspec:selector:matchLabels:name:fluentd-elasticsearchupdateStrategy:type:RollingUpdaterollingUpdate:maxUnavailable:1template:metadata:labels:name:fluentd-elasticsearchspec:tolerations:# 이 톨러레이션(toleration)은 마스터 노드에서 실행 가능한 데몬셋이# 마스터에서 파드를 실행할 수 없는 경우 이를 제거하는 것이다- key:node-role.kubernetes.io/mastereffect:NoSchedulecontainers:- name:fluentd-elasticsearchimage:quay.io/fluentd_elasticsearch/fluentd:v2.5.2volumeMounts:- name:varlogmountPath:/var/log- name:varlibdockercontainersmountPath:/var/lib/docker/containersreadOnly:trueterminationGracePeriodSeconds:30volumes:- name:varloghostPath:path:/var/log- name:varlibdockercontainershostPath:path:/var/lib/docker/containers
apiVersion:apps/v1kind:DaemonSetmetadata:name:fluentd-elasticsearchnamespace:kube-systemlabels:k8s-app:fluentd-loggingspec:selector:matchLabels:name:fluentd-elasticsearchupdateStrategy:type:RollingUpdaterollingUpdate:maxUnavailable:1template:metadata:labels:name:fluentd-elasticsearchspec:tolerations:# 이 톨러레이션(toleration)은 마스터 노드에서 실행 가능한 데몬셋이# 마스터에서 파드를 실행할 수 없는 경우 이를 제거하는 것이다- key:node-role.kubernetes.io/mastereffect:NoSchedulecontainers:- name:fluentd-elasticsearchimage:quay.io/fluentd_elasticsearch/fluentd:v2.5.2resources:limits:memory:200Mirequests:cpu:100mmemory:200MivolumeMounts:- name:varlogmountPath:/var/log- name:varlibdockercontainersmountPath:/var/lib/docker/containersreadOnly:trueterminationGracePeriodSeconds:30volumes:- name:varloghostPath:path:/var/log- name:varlibdockercontainershostPath:path:/var/lib/docker/containers
# --to-revision에 1단계에서 얻는 리비전 번호를 지정한다
kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>
성공하면, 명령은 다음을 반환한다.
daemonset "<daemonset-name>" rolled back
참고:--to-revision 플래그를 지정하지 않은 경우, kubectl은 가장 최신의 리비전을 선택한다.
3단계: 데몬셋 롤백 진행 상황 확인
kubectl rollout undo daemonset 은 서버에 데몬셋 롤백을 시작하도록
지시한다. 실제 롤백은 클러스터 컨트롤 플레인
내에서 비동기적으로 수행된다.
롤백 진행 상황을 보려면 다음의 명령을 수행한다.
kubectl rollout status ds/<daemonset-name>
롤백이 완료되면, 출력 결과는 다음과 비슷하다.
daemonset "<daemonset-name>" successfully rolled out
데몬셋 리비전의 이해
이전 kubectl rollout history 단계에서, 데몬셋 리비전 목록을
얻었다. 각 리비전은 ControllerRevision이라는 리소스에 저장된다.
각 리비전에 저장된 내용을 보려면, 데몬셋 리비전 원시 리소스를
찾는다.
kubectl get controllerrevision -l <daemonset-selector-key>=<daemonset-selector-value>
이 명령은 ControllerRevision의 목록을 반환한다.
NAME CONTROLLER REVISION AGE
<daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 1 1h
<daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 2 1h
각 ControllerRevision은 데몬셋 리비전의 어노테이션과 템플릿을
저장한다.
kubectl rollout undo 는 특정 ControllerRevision을 가져와 데몬셋
템플릿을 ControllerRevision에 저장된 템플릿으로 바꾼다.
kubectl rollout undo 는 kubectl edit 또는 kubectl apply 와 같은 다른 명령을 통해
데몬셋 템플릿을 이전 리비전으로 업데이트하는 것과
같다.
참고: 데몬셋 리비전은 롤 포워드만 한다. 즉, 롤백이
완료된 후, 롤백될 ControllerRevision의
리비전 번호(.revision 필드)가 증가한다. 예를 들어,
시스템에 리비전 1과 2가 있고, 리비전 2에서 리비전 1으로 롤백하면,
ControllerRevision은 .revision: 1 에서 .revision: 3 이 된다.
쿠버네티스 서버의 버전은 다음과 같아야 함. 버전: v1.20.
버전 확인을 위해서, 다음 커맨드를 실행 kubectl version.
어드레싱 검증
노드 어드레싱 검증
각각의 이중 스택 노드는 단일 IPv4 블록 및 단일 IPv6 블록을 할당받아야 한다. IPv4/IPv6 파드 주소 범위를 다음 커맨드를 실행하여 검증한다. 샘플 노드 이름을 클러스터 내 검증된 이중 스택 노드로 대체한다. 본 예제에서, 노드 이름은 k8s-linuxpool1-34450317-0 이다.
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}'
10.244.1.0/24
a00:100::/24
단일 IPv4 블록과 단일 IPv6 블록이 할당되어야 한다.
노드가 IPv4 및 IPv6 인터페이스를 가지고 있는지 검증한다. (노드 이름을 클러스터의 검증된 노드로 대체한다. 본 예제에서 노드 이름은 k8s-linuxpool1-34450317-0) 이다.
.spec.ipFamilyPolicy 를 명시적으로 정의하지 않은 다음의 서비스를 생성한다. 쿠버네티스는 처음 구성된 service-cluster-ip-range 에서 서비스에 대한 클러스터 IP를 할당하고 .spec.ipFamilyPolicy 를 SingleStack 으로 설정한다.
이 서비스에서 .spec.ipFamilyPolicy 를 SingleStack 으로 설정하고 .spec.clusterIP 를 kube-controller-manager의 --service-cluster-ip-range 플래그를 통해 설정된 첫 번째 구성 범위에서 IPv4 주소로 설정한다.
.spec.ipFamilies 의 첫 번째 배열 요소로 IPv6 을 명시적으로 정의하는 다음 서비스를 생성한다. Kubernetes는 service-cluster-ip-range로 구성된 IPv6 범위에서 서비스용 클러스터 IP를 할당하고 .spec.ipFamilyPolicy 를 SingleStack 으로 설정한다.
이 서비스에서 .spec.ipFamilyPolicy 를 SingleStack 으로 설정하고 .spec.clusterIP 를 kube-controller-manager의 --service-cluster-ip-range 플래그를 통해 설정된 IPv6 범위에서 IPv6 주소로 설정한다.
PreferDualStack 에 .spec.ipFamilyPolicy 을 명시적으로 정의하는 다음 서비스를 생성한다. 쿠버네티스는 IPv4 및 IPv6 주소를 모두 할당하고 (이 클러스터에는 이중 스택을 사용하도록 설정되었으므로) .spec.ipFamilies 배열에 있는 첫 번째 요소의 주소 계열을 기반으로.spec.ClusterIP 목록에서 .spec.ClusterIPs 를 선택한다.
만약 클라우드 제공자가 IPv6 기반 외부 로드 밸런서 구성을 지원한다면 .spec.ipFamilyPolicy 의 PreferDualStack 과 .spec.ipFamilies 배열의 첫 번째 요소로 IPv6 및 LoadBalancer 로 설정된 type 필드를 사용하여 다음 서비스를 생성한다.
apiVersion:v1kind:Podmetadata:name:cuda-vector-addspec:restartPolicy:OnFailurecontainers:- name:cuda-vector-add# https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfileimage:"k8s.gcr.io/cuda-vector-add:v0.1"resources:limits:nvidia.com/gpu:1nodeSelector:accelerator:nvidia-tesla-p100# 또는 nvidia-tesla-k80 등.
이것은 파드가 사용자가 지정한 GPU 타입을 가진 노드에 스케줄 되도록
만든다.
4.15 - HugePages 관리
클러스터에서 huge page를 스케줄할 수 있는 리소스로 구성하고 관리한다.
FEATURE STATE:Kubernetes v1.20 [stable]
쿠버네티스는 파드의 애플리케이션에 미리 할당된
huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 huge page를 사용하는 방법에 대해 설명한다.
시작하기 전에
쿠버네티스 노드는 노드에 대한 huge page 용량을 보고하기 위해
huge page를 미리 할당해야 한다. 노드는 여러 크기의 huge page를 미리 할당할 수
있다.
노드는 모든 huge page 리소스를 스케줄 가능한 리소스로 자동 검색하고
보고한다.
API
리소스 이름 hugepages-<size> (<size> 는 특정 노드에서 지원되는 정수값을
사용하는 가장 간단한 2진 표기법)를 사용하여 컨테이너 레벨의 리소스
요구 사항을 통해 huge page를 사용할 수 있다. 예를 들어,
노드가 2048KiB 및 1048576KiB 페이지 크기를 지원하는 경우, 스케줄 가능한
리소스인 hugepages-2Mi 와 hugepages-1Gi 를 노출한다. CPU나 메모리와 달리,
huge page는 오버커밋을 지원하지 않는다. 참고로 hugepage 리소스를 요청하는 경우,
메모리 또는 CPU 리소스도 요청해야 한다.
파드는 단일 파드 스펙에 여러 개의 huge page 크기를 사용할 수 있다. 이 경우
모든 볼륨 마운트에 대해 medium: HugePages-<hugepagesize> 표기법을 사용해야 한다.
Huge page 요청(requests)은 제한(limits)과 같아야 한다. 제한이 지정되었지만, 요청은 지정되지 않은 경우
이것이 기본값이다.
Huge page는 컨테이너 범위에서 격리되므로, 각 컨테이너에는 컨테이너 사양에서 요청한대로
cgroup 샌드박스에 대한 제한이 있다.
Huge page가 지원하는 EmptyDir 볼륨은 파드 요청보다 더 많은 huge page 메모리를
사용하지 말아야 한다.
shmget() 의 SHM_HUGETLB 를 통해 huge page를 사용하는 애플리케이션은
proc/sys/vm/hugetlb_shm_group 과 일치하는 보충 그룹(supplemental group)으로 실행해야 한다.
네임스페이스에서의 huge page 사용은 hugepages-<size> 토큰을 사용하는 cpu 또는 memory 와 같은
다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수
있다.
다양한 크기의 huge page 지원이 기능 게이트로 제공된다.
kubelet 및
kube-apiserver
(--feature-gates=HugePageStorageMediumSize=true)의 HugePageStorageMediumSize기능 게이트를
사용하여 비활성화할 수 있다.
4.16 - 플러그인으로 kubectl 확장
kubectl 플러그인을 작성하고 설치해서 kubectl을 확장한다.
이 가이드는 kubectl 확장을 설치하고 작성하는 방법을 보여준다. 핵심 kubectl 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는
플러그인을 이러한 구성 요소를 활용하여 보다 복잡한 동작을 만드는 수단으로 생각할 수 있다. 플러그인은 새로운 하위 명령으로 kubectl 을 확장하고, 주요 배포판에 포함되지 않은 kubectl 의 새로운 사용자 정의 기능을 허용한다.
시작하기 전에
동작하는 kubectl 바이너리가 설치되어 있어야 한다.
kubectl 플러그인 설치
플러그인은 이름이 kubectl- 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 실행 파일을 PATH 에 지정된 디렉터리로 옮기면 된다.
Krew를 사용하여 오픈소스에서 사용 가능한
kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네티스 SIG CLI 커뮤니티에서 관리하는
플러그인 관리자이다.
주의: Krew 플러그인 인덱스를 통해 사용할 수 있는 kubectl 플러그인은
보안 감사를 받지 않는다. 써드파티 플러그인은 시스템에서 실행되는 임의의
프로그램이므로, 사용자는 이를 인지한 상태에서 설치하고 실행해야 한다.
플러그인 디스커버리
kubectl 은 유효한 플러그인 실행 파일을 PATH 에서 검색하는 kubectl plugin list 명령을 제공한다.
이 명령을 실행하면 PATH 에 있는 모든 파일을 탐색한다. 실행 가능하고, kubectl- 로 시작하는 모든 파일은 이 명령의 출력 결과에 PATH 에 있는 순서대로 표시된다.
실행 파일이 아닌 파일이 kubectl- 시작하는 경우 경고가 포함된다.
서로의 이름과 겹치는 유효한 플러그인 파일에 대한 경고도 포함된다.
Krew를 사용하여 커뮤니티가 관리하는
플러그인 인덱스에서 kubectl
플러그인을 검색하고 설치할 수 있다.
제한 사항
현재 기존 kubectl 명령을 덮어 쓰는 플러그인을 생성할 수 없다. 예를 들어, 플러그인 kubectl-version 을 만들면 기존의 kubectl version 명령이 항상 우선하므로, 플러그인이 실행되지 않는다. 이 제한으로 인해, 플러그인을 사용하여 기존 kubectl 명령에 새로운 하위 명령을 추가할 수도 없다. 예를 들어, 플러그인 이름을 kubectl-create-foo 로 지정하여 kubectl create foo 하위 명령을 추가하면 해당 플러그인이 무시된다.
kubectl plugin list 는 이를 시도하는 유효한 플러그인에 대한 경고를 표시한다.
kubectl 플러그인 작성
커맨드-라인 명령을 작성할 수 있는 프로그래밍 언어나 스크립트로 플러그인을 작성할 수 있다.
플러그인 설치 또는 사전 로딩이 필요하지 않다. 플러그인 실행 파일은
kubectl 바이너리에서 상속된 환경을 받는다.
플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다.
예를 들어, kubectl-foo 라는 플러그인은 kubectl foo 명령을 제공한다.
PATH 어딘가에 플러그인 실행 파일을 설치해야 한다.
플러그인 예제
#!/bin/bash
# 선택적 인수 처리if[["$1"=="version"]]thenecho"1.0.0"exit0fi# 선택적 인수 처리if[["$1"=="config"]]thenecho"$KUBECONFIG"exit0fiecho"I am a plugin named kubectl-foo"
또한, 플러그인으로 전달되는 첫 번째 인수는 항상 호출된 위치의 전체 경로이다(위의 예에서 $0 은 /usr/local/bin/kubectl-foo 와 동일하다).
플러그인 이름 지정
위 예제에서 볼 수 있듯이, 플러그인은 파일명을 기반으로 구현할 명령 경로를 결정한다. 플러그인이 대상으로 하는 명령 경로의 모든 하위 명령은 대시(-)로 구분된다.
예를 들어, 사용자가 kubectl foo bar baz 명령을 호출할 때마다 호출되는 플러그인은 파일명이 kubectl-foo-bar-baz 이다.
플래그와 인수 처리
참고:
플러그인 메커니즘은 플러그인 프로세스에 대한 사용자 정의, 플러그인 특정 값 또는 환경 변수를 생성하지 않는다.
이전 kubectl 플러그인 메커니즘은 KUBECTL_PLUGINS_CURRENT_NAMESPACE 와 같이 더이상 사용하지 않는 환경 변수를 제공했다.
kubectl 플러그인은 전달된 모든 인수를 파싱하고 유효성을 검사해야 한다.
플러그인 작성자를 대상으로 하는 Go 라이브러리에 대한 자세한 내용은 커맨드 라인 런타임 패키지 사용을 참고한다.
다음은 사용자가 추가 플래그와 인수를 제공하면서 플러그인을 호출하는 추가 사례이다. 이것은 위 시나리오의 kubectl-foo-bar-baz 플러그인을 기반으로한다.
kubectl foo bar baz arg1 --flag=value arg2 를 실행하면, kubectl의 플러그인 메커니즘은 먼저 가장 긴 가능한 이름을 가진 플러그인을 찾으려고 시도한다. 여기서는
kubectl-foo-bar-baz-arg1 이다. 해당 플러그인을 찾지 못하면, kubectl은 대시로 구분된 마지막 값을 인수(여기서는 arg1)로 취급하고, 다음으로 가장 긴 가능한 이름인 kubectl-foo-bar-baz 를 찾는다.
이 이름의 플러그인을 찾으면, kubectl은 해당 플러그인을 호출하여, 플러그인 이름 뒤에 모든 인수와 플래그를 플러그인 프로세스의 인수로 전달한다.
예:
# 플러그인 생성echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
sudo chmod +x ./kubectl-foo-bar-baz
# $PATH에 있는 디렉터리로 옮겨 플러그인을 "설치"
sudo mv ./kubectl-foo-bar-baz /usr/local/bin
# 플러그인을 kubectl이 인식하는지 확인
kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-foo-bar-baz
# test that calling your plugin via a "kubectl" command works
# even when additional arguments and flags are passed to your
# plugin executable by the user.
kubectl foo bar baz arg1 --meaningless-flag=true
My first command-line argument was arg1
보시다시피, 사용자가 지정한 kubectl 명령을 기반으로 플러그인을 찾았으며, 모든 추가 인수와 플래그는 플러그인 실행 파일이 발견되면 그대로 전달된다.
대시와 언더스코어가 있는 이름
kubectl 플러그인 메커니즘은 플러그인 파일명에 대시(-)를 사용하여 플러그인이 처리하는 하위 명령 시퀀스를 분리하지만, 파일명에
언더스코어(_)를 사용하여 커맨드 라인 호출에 대시를 포함하는 플러그인 명령을 생성할 수 있다.
예:
# 파일명에 언더스코어(_)가 있는 플러그인 생성echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
sudo chmod +x ./kubectl-foo_bar
# $PATH에 플러그인을 옮긴다
sudo mv ./kubectl-foo_bar /usr/local/bin
# 이제 kubectl을 통해 플러그인을 사용할 수 있다
kubectl foo-bar
I am a plugin with a dash in my name
참고로 플러그인 파일명에 언더스코어를 추가해도 kubectl foo_bar 와 같은 명령을 사용할 수 있다.
위 예에서 명령은 대시(-) 또는 언더스코어(_)을 사용하여 호출할 수 있다.
# 대시를 포함한 사용자 정의 명령을 사용할 수 있다
kubectl foo-bar
I am a plugin with a dash in my name
# 언더스코어를 포함한 사용자 정의 명령을 사용할 수도 있다
kubectl foo_bar
I am a plugin with a dash in my name
이름 충돌과 오버셰도잉(overshadowing)
PATH 의 다른 위치에 동일한 파일명을 가진 여러 플러그인이 있을 수 있다.
예를 들어, PATH 값이 PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins 로 주어지고, kubectl-foo 플러그인을 복사한 파일이 /usr/local/bin/plugins 와 /usr/local/bin/moreplugins 에 있을 수 있다.
kubectl plugin list 명령의 출력 결과는 다음과 같다.
PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/plugins/kubectl-foo
/usr/local/bin/moreplugins/kubectl-foo
- warning: /usr/local/bin/moreplugins/kubectl-foo is overshadowed by a similarly named plugin: /usr/local/bin/plugins/kubectl-foo
error: one plugin warning was found
위 시나리오에서, /usr/local/bin/moreplugins/kubectl-foo 아래의 경고는 이 플러그인이 실행되지 않을 것임을 알려준다. 대신, PATH 에 먼저 나타나는 실행 파일인 /usr/local/bin/plugins/kubectl-foo 는 항상 발견되고 kubectl 플러그인 메카니즘에 의해 먼저 실행된다.
이 문제를 해결하는 방법은 kubectl 와 함께 사용하려는 플러그인의 위치가 PATH 에 항상에서 먼저 오도록 하는 것이다. 예를 들어, kubectl 명령 kubectl foo 가 호출될 때마다 항상 /usr/local/bin/moreplugins/kubectl-foo 를 사용하려면, PATH 의 값을 /usr/local/bin/moreplugins:/usr/local/bin/plugins 로 변경한다.
가장 긴 실행 파일명의 호출
플러그인 파일명으로 발생할 수 있는 또 다른 종류의 오버셰도잉이 있다. 사용자의 PATH 에 kubectl-foo-bar 와 kubectl-foo-bar-baz 라는 두 개의 플러그인이 있다면, kubectl 플러그인 메커니즘은 항상 주어진 사용자의 명령에 대해 가장 긴 가능한 플러그인 이름을 선택한다. 아래에 몇 가지 예가 있다.
# 주어진 kubectl 명령의 경우, 가장 긴 가능한 파일명을 가진 플러그인이 항상 선호된다
kubectl foo bar baz
Plugin kubectl-foo-bar-baz is executed
kubectl foo bar
Plugin kubectl-foo-bar is executed
kubectl foo bar baz buz
Plugin kubectl-foo-bar-baz is executed, with "buz" as its first argument
kubectl foo bar buz
Plugin kubectl-foo-bar is executed, with "buz" as its first argument
이 디자인 선택은 필요한 경우 여러 파일에 플러그인 하위 명령을 구현할 수 있도록 하고 이러한 하위 명령을 "부모" 플러그인 명령 아래에 중첩할 수 있도록 한다.
위에서 언급한 kubectl plugin list 명령을 사용하여 kubectl 에 의해 플러그인이 표시되는지 확인하고, kubectl 명령으로 호출되지 못하게 하는 경고가 없는지 확인할 수 있다.
kubectl plugin list
The following kubectl-compatible plugins are available:
test/fixtures/pkg/kubectl/plugins/kubectl-foo
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo is overshadowed by a similarly named plugin: test/fixtures/pkg/kubectl/plugins/kubectl-foo
plugins/kubectl-invalid
- warning: plugins/kubectl-invalid identified as a kubectl plugin, but it is not executable
error: 2 plugin warnings were found
커맨드 라인 런타임 패키지 사용
kubectl 용 플러그인을 작성하고 있고 Go를 사용한다면,
cli-runtime 유틸리티 라이브러리를
사용할 수 있다.
이 라이브러리는 사용자의
kubeconfig
파일을 파싱이나 업데이트하거나, REST 스타일의 요청을 API 서버에 작성하거나, 구성 및 출력과
관련된 플래그를 바인딩하기 위한 헬퍼를 제공한다.
다른 사람이 사용할 수 있는 플러그인을 개발한 경우, 이를 패키징하고, 배포하고
사용자에게 업데이트를 제공하는 방법을 고려해야 한다.
Krew
Krew는 플러그인을 패키징하고 배포하는 크로스-플랫폼
방식을 제공한다. 이렇게 하면, 모든 대상 플랫폼(리눅스, 윈도우, macOS 등)에
단일 패키징 형식을 사용하고 사용자에게 업데이트를 제공한다.
Krew는 또한 다른 사람들이 여러분의 플러그인을 검색하고 설치할 수 있도록
플러그인 인덱스를
유지 관리한다.
네이티브 / 플랫폼 별 패키지 관리
다른 방법으로는, 리눅스의 apt 나 yum,
윈도우의 Chocolatey, macOS의 Homebrew와 같은 전통적인 패키지 관리자를 사용할 수 있다.
새 실행 파일을 사용자의 PATH 어딘가에 배치할 수 있는 패키지 관리자라면
어떤 패키지 관리자도 괜찮다.
플러그인 작성자로서, 이 옵션을 선택하면 각 릴리스의 여러 플랫폼에서
kubectl 플러그인의 배포 패키지를
업데이트해야 한다.
소스 코드
소스 코드를 게시(예를 들어, Git 리포지터리)할 수 있다. 이
옵션을 선택하면, 해당 플러그인을 사용하려는 사람이 코드를 가져와서,
빌드 환경을 설정하고(컴파일이 필요한 경우), 플러그인을 배포해야 한다.
컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가
더 쉬워진다.
다음 내용
Go로 작성된 플러그인의
자세한 예제에 대해서는
샘플 CLI 플러그인 리포지터리를 확인한다.
궁금한 사항이 있으면,
SIG CLI 팀에 문의한다.
쿠버네티스 문서의 본 섹션은 튜토리얼을 포함하고 있다.
튜토리얼은 개별 작업 단위보다 더 큰 목표를 달성하기
위한 방법을 보여준다. 일반적으로 튜토리얼은 각각 순차적 단계가 있는 여러
섹션으로 구성된다.
각 튜토리얼을 따라하기 전에, 나중에 참조할 수 있도록
표준 용어집 페이지를 북마크하기를 권한다.
기초
쿠버네티스 기초는 쿠버네티스 시스템을 이해하는데 도움이 되고 기초적인 쿠버네티스 기능을 일부 사용해 볼 수 있는 심도있는 대화형 튜토리얼이다.
Ctrl+C 를 눌러 프록시를 종료할 수 있다. 대시보드는 종료되지 않고 실행 상태로 남아 있다.
URL을 이용하여 대시보드 접속하기
자동으로 웹 브라우저가 열리는 것을 원치 않는다면, 다음과 같은 명령어를 실행하여 대시보드 접속 URL을 출력할 수 있다:
minikube dashboard --url
디플로이먼트 만들기
쿠버네티스 파드는 관리와
네트워킹 목적으로 함께 묶여 있는 하나 이상의 컨테이너 그룹이다.
이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스
디플로이먼트는 파드의
헬스를 검사해서 파드의 컨테이너가 종료되었다면 재시작해준다.
파드의 생성 및 스케일링을 관리하는 방법으로 디플로이먼트를 권장한다.
kubectl create 명령어를 실행하여 파드를 관리할 디플로이먼트를 만든다. 이
파드는 제공된 Docker 이미지를 기반으로 한 컨테이너를 실행한다.
--type=LoadBalancer플래그는 클러스터 밖의 서비스로 노출하기
원한다는 뜻이다.
k8s.gcr.io/echoserver 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. kubectl expose를
사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다.
생성한 서비스 살펴보기
kubectl get services
다음과 유사하게 출력된다.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
로드 밸런서를 지원하는 클라우드 공급자의 경우에는
서비스에 접근할 수 있도록 외부 IP 주소가 프로비저닝 한다.
minikube에서 LoadBalancer타입은 minikube service 명령어를 통해서 해당 서비스를 접근할 수
있게 한다.
다음 명령어를 실행한다
minikube service hello-node
Katacoda 환경에서만: 플러스를 클릭한 후에 Select port to view on Host 1 를 클릭.
Katacoda 환경에서만: 서비스 출력에서 8080의 반대편에 표시되는 5자리 포트 번호를 기록 한다. 이 포트 번호는 무작위로 생성되며, 사용자마다 다를 수 있다. 포트 번호 텍스트 상자에 포트 번호를 입력한 다음, 포트 표시를 클릭한다. 이전 예시를 사용해서 30369 를 입력한다.
이렇게 하면 당신의 앱을 서비스하는 브라우저 윈도우를 띄우고 애플리케이션의 응답을 볼 수 있다.
애드온 사용하기
minikube 툴은 활성화하거나 비활성화할 수 있고 로컬 쿠버네티스 환경에서 접속해 볼 수 있는 내장 애드온 셋이 포함되어 있다.
이 튜토리얼에서는 쿠버네티스 클러스터 오케스트레이션 시스템의 기초를 익힐 수 있는 가이드를 제공한다. 각각의 모듈에는 쿠버네티스의 주요 기능과 개념에 대한 배경 지식이 담겨 있으며 대화형 온라인 튜토리얼도 포함되어 있다. 대화형 튜토리얼에서 간단한 클러스터와 그 클러스터 상의 컨테이너화 된 애플리케이션을 직접 관리해볼 수 있다.
대화형 튜토리얼을 사용해서 다음의 내용을 배울 수 있다.
컨테이너화된 애플리케이션을 클러스터에 배포하기.
디플로이먼트를 스케일링하기.
컨테이너화된 애플리케이션을 새로운 소프트웨어 버전으로 업데이트하기.
컨테이너화된 애플리케이션을 디버그하기.
이 튜토리얼에서는 Katacoda를 사용해서 독자의 웹브라우저에서 Minikube가 동작하는 가상 터미널을 구동시킨다. Minikube는 로컬에 설치할 수 있는 작은 규모의 쿠버네티스로써 어디에서든 작동된다. 어떤 소프트웨어도 설치할 필요가 없고, 아무 것도 설정할 필요가 없다. 왜냐하면 대화형 튜토리얼이 웹브라우저 자체에서 바로 동작하기 때문이다.
쿠버네티스가 어떤 도움이 될까?
오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다.
쿠버네티스는 컴퓨터들을 연결하여 단일 형상으로 동작하도록 컴퓨팅 클러스터를 구성하고 높은 가용성을 제공하도록 조율한다. 사용자는 쿠버네티스의 추상화 개념을 통해 개별 머신에 얽매이지 않고 컨테이너화된 애플리케이션을 클러스터에 배포할 수 있다. 이렇게 새로운 배포 모델을 활용하려면, 애플리케이션을 개별 호스트에 독립적인 방식으로 패키징할 필요가 있다. 즉, 컨테이너화가 필요하다. 예전 배치 모델인 설치형 애플리케이션이 특정 머신의 호스트와 밀접하게 통합되는 패키지인 것에 비해, 컨테이너화된 애플리케이션은 유연성(flexible)과 가용성(available)이 훨씬 높다. 쿠버네티스는 이러한 애플리케이션 컨테이너를 클러스터에 분산시키고 스케줄링하는 일을 더욱 효율적으로 자동화한다. 쿠버네티스는 오픈소스 플랫폼이며 운영 수준의 안정성(production-ready)을 제공한다.
쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다.
컨트롤 플레인은 클러스터를 조율한다.
노드는 애플리케이션을 구동하는 작업자(worker)이다.
요약:
쿠버네티스 클러스터
Minikube
쿠버네티스는 컴퓨터 클러스터에 애플리케이션 컨테이너의 배치(스케줄링) 및 실행을 오케스트레이션하는 운영 수준의 오픈소스 플랫폼이다.
클러스터 다이어그램
컨트롤 플레인은 클러스터 관리를 담당한다. 컨트롤 플레인은 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.
노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다. 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.
컨트롤 플레인은 실행 중인 애플리케이션을 호스팅하기 위해 사용되는 노드와 클러스터를 관리한다.
애플리케이션을 쿠버네티스에 배포하기 위해서는, 컨트롤 플레인에 애플리케이션 컨테이너의 구동을 지시하면 된다. 그러면 컨트롤 플레인은 컨테이너를 클러스터의 어느 노드에 구동시킬지 스케줄한다. 노드는 컨트롤 플레인이 제공하는 쿠버네티스 API를 통해서 컨트롤 플레인과 통신한다. 최종 사용자도 쿠버네티스 API를 사용해서 클러스터와 직접 상호작용(interact)할 수 있다.
쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면 Minikube를 사용할 수 있다. Minikube는 가벼운 쿠버네티스 구현체이며, 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한 클러스터를 생성한다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서 구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인 부트스트래핑(bootstrapping) 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는 온라인 터미널을 사용할 것이다.
쿠버네티스가 무엇인지 알아봤으니, 이제 온라인 튜토리얼로 이동해서 우리의 첫 번째 클러스터를 시작해보자!
일단 쿠버네티스 클러스터를 구동시키면, 그 위에 컨테이너화된 애플리케이션을 배포할 수 있다.
그러기 위해서, 쿠버네티스 디플로이먼트 설정을 만들어야 한다. 디플로이먼트는 쿠버네티스가
애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시한다. 디플로이먼트가 만들어지면,
쿠버네티스 컨트롤 플레인이 해당 디플로이먼트에 포함된 애플리케이션 인스턴스가 클러스터의 개별 노드에서 실행되도록 스케줄한다.
애플리케이션 인스턴스가 생성되면, 쿠버네티스 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를
모니터링한다. 인스턴스를 구동 중인 노드가 다운되거나 삭제되면, 디플로이먼트 컨트롤러가 인스턴스를
클러스터 내부의 다른 노드의 인스턴스로 교체시켜준다.이렇게 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing) 메커니즘을
제공한다.
오케스트레이션 기능이 없던 환경에서는, 설치 스크립트가 애플리케이션을 시작하는데 종종 사용되곤
했지만, 머신의 장애가 발생한 경우 복구를 해주지는 않았다. 쿠버네티스 디플로이먼트는 애플리케이션
인스턴스를 생성해주고 여러 노드에 걸쳐서 지속적으로 인스턴스가 구동되도록 하는 두 가지를 모두
하기 때문에 애플리케이션 관리를 위한 접근법에서 근본적인 차이를 가져다준다.
요약:
디플로이먼트
Kubectl
디플로이먼트는 애플리케이션 인스턴스를 생성하고 업데이트하는 역할을 담당한다.
쿠버네티스에 첫 번째 애플리케이션 배포하기
Kubectl이라는 쿠버네티스 CLI를 통해 디플로이먼트를 생성하고 관리할 수 있다.
Kubectl은 클러스터와 상호 작용하기 위해 쿠버네티스 API를 사용한다. 이 모듈에서는, 쿠버네티스
클러스터 상에 애플리케이션을 구동시키는 디플로이먼트를 생성하기 위해 필요한 가장 일반적인 Kubectl
명령어를 배우게 된다.
디플로이먼트를 생성할 때, 애플리케이션에 대한 컨테이너 이미지와 구동시키고자 하는 복제 수를 지정해야
한다. 디플로이먼트를 업데이트해서 이런 정보를 나중에 변경할 수 있다. 모듈
5와 6의 부트캠프에서 어떻게
스케일하고 업데이트하는지에 대해 다룬다.
애플리케이션이 쿠버네티스 상에 배포되려면 지원되는 컨테이너 형식 중 하나로 패키지 되어야한다.
첫 번째 디플로이먼트로, NGINX를 사용해 모든 요청을 에코(echo)하는 도커 컨테이너로 패키지한 hello-node 애플리케이션을 사용해보자. (아직 hello-node 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면, Hello Minikube 튜토리얼의 지시를 따른다.)
이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자!
모듈 2에서 배포를 생성했을 때, 쿠버네티스는 여러분의 애플리케이션 인스턴스에 파드를 생성했다. 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다:
볼륨과 같은, 공유 스토리지
클러스터 IP 주소와 같은, 네트워킹
컨테이너 이미지 버전 또는 사용할 특정 포트와 같이, 각 컨테이너가 동작하는 방식에 대한 정보
파드는 특유한 "로컬호스트" 애플리케이션 모형을 만들어. 상대적으로 밀접하게 결합되어진 상이한 애플리케이션 컨테이너들을 수용할 수 있다. 가령, 파드는 Node.js 앱과 더불어 Node.js 웹서버에 의해 발행되는 데이터를 공급하는 상이한 컨테이너를 함께 수용할 수 있다. 파드 내 컨테이너는 IP 주소, 그리고 포트 스페이스를 공유하고 항상 함께 위치하고 함께 스케쥴링 되고 동일 노드 상의 컨텍스트를 공유하면서 동작한다.
파드는 쿠버네티스 플랫폼 상에서 최소 단위가 된다. 우리가 쿠버네티스에서 배포를 생성할 때, 그 배포는 컨테이너 내부에서 컨테이너와 함께 파드를 생성한다. 각 파드는 스케쥴 되어진 노드에게 묶여지게 된다. 그리고 (재구동 정책에 따라) 소멸되거나 삭제되기 전까지 그 노드에 유지된다. 노드에 실패가 발생할 경우, 클러스터 내에 가용한 다른 노드들을 대상으로 스케쥴되어진다.
요약:
파드
노드
Kubectl 주요 명령어
파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹이고 공유 스토리지 (볼륨), IP 주소 그리고 그것을 동작시키는 방식에 대한 정보를 포함하고 있다.
파드 개요
노드
파드는 언제나 노드 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 마스터에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 마스터는 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다.
모든 쿠버네티스 노드는 최소한 다음과 같이 동작한다.
Kubelet은, 쿠버네티스 마스터와 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리한다.
컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다.
만약 컨테이너들이 밀접하고 결합되어 있고 디스크와 같은 자원을 공유해야 한다면 오직 하나의 단일 파드에 함께 스케쥴되어져야 한다.
노드 개요
kubectl로 문제해결하기
모듈 2에서, Kubectl 커맨드-라인 인터페이스를 사용했다. 배포된 애플리케이션과 그 환경에 대한 정보를 얻기 위해 모듈3에서도 계속 그것을 사용할 것이다. 가장 보편적인 운용업무는 다음 kubectl 명령어를 이용하여 처리할 수 있다:
kubectl get - 자원을 나열한다
kubectl describe - 자원에 대해 상세한 정보를 보여준다.
kubectl logs - 파드 내 컨테이너의 로그들을 출력한다
kubectl exec - 파드 내 컨테이너에 대한 명령을 실행한다.
언제 애플리케이션이 배포되었으며, 현재 상태가 어떠한지, 그것의 구성은 어떠한지 등을 보기 위해 이러한 명령을 이용할 수 있다.
이제 클러스터 컴포넌트와 커맨드 라인에 대해 알아 보았으니, 애플리케이션을 조사해 보자.
노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있다. 여러 개의 파드는 하나의 노드 위에서 동작할 수 있다.
쿠버네티스 파드들 은 언젠가는 죽게된다. 실제 파드들은 생명주기를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. 레플리카셋(ReplicaSet)은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.
쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML (보다 선호하는) 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 LabelSelector에 의해 결정된다 (여러분이 왜 스펙에 selector가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).
비록 각 파드들이 고유의 IP를 갖고 있기는 하지만, 그 IP들은 서비스의 도움없이 클러스터 외부로 노출되어질 수 없다. 서비스들은 여러분의 애플리케이션들에게 트래픽이 실릴 수 있도록 허용해준다. 서비스들은 ServiceSpec에서 type을 지정함으로써 다양한 방식들로 노출시킬 수 있다:
ClusterIP (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.
NodePort - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. <NodeIP>:<NodePort>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합이다.
LoadBalancer - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다.
ExternalName - CNAME 레코드 및 값을 반환함으로써 서비스를 externalName 필드의 내용(예를 들면, `foo.bar.example.com`)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 kube-dns v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.
부가적으로, spec에 selector를 정의하지 않고 말아넣은 서비스들의 몇 가지 유즈케이스들이 있음을 주의하자. selector 없이 생성된 서비스는 상응하는 엔드포인트 오브젝트들 또한 생성하지 않는다. 이로써 사용자들로 하여금 하나의 서비스를 특정한 엔드포인트에 매핑 시킬수 있도록 해준다. selector를 생략하게 되는 또 다른 가능성은 여러분이 type: ExternalName을 이용하겠다고 확고하게 의도하는 경우이다.
요약
파드들을 외부 트래픽에 노출하기
여러 파드에 걸쳐서 트래픽 로드밸런싱 하기
레이블 사용하기
쿠버네티스 서비스는 논리적 파드 셋을 정의하고 외부 트래픽 노출, 로드밸런싱 그리고 그 파드들에 대한 서비스 디스커버리를 가능하게 해주는 추상 계층이다.
서비스와 레이블
서비스는 파드 셋에 걸쳐서 트래픽을 라우트한다. 여러분의 애플리케이션에 영향을 주지 않으면서 쿠버네티스에서 파드들이 죽게도 하고, 복제가 되게도 해주는 추상적 개념이다. 종속적인 파드들 사이에서의 디스커버리와 라우팅은 (하나의 애플리케이션에서 프로트엔드와 백엔드 컴포넌트와 같은) 쿠버네티스 서비스들에 의해 처리된다.
서비스는 쿠버네티스의 객체들에 대해 논리 연산을 허용해주는 기본 그룹핑 단위인, 레이블과 셀렉터를 이용하여 파드 셋과 매치시킨다. 레이블은 오브젝트들에 붙여진 키/밸류 쌍으로 다양한 방식으로 이용 가능하다:
개발, 테스트, 그리고 상용환경에 대한 객체들의 지정
임베디드된 버전 태그들
태그들을 이용하는 객체들에 대한 분류
레이블은 오브젝트의 생성 시점 또는 이후 시점에 붙여질 수 있다. 언제든지 수정이 가능하다. 이제 서비스를 이용하여 우리의 애플리케이션을 노출도 시켜보고 레이블도 적용해 보자.
디플로이먼트를 스케일 아웃하면 신규 파드가 생성되어서 가용한 자원이 있는 노드에 스케줄된다.
스케일링 기능은 새로 의도한 상태(desired state)까지 파드의 수를 늘린다. 쿠버네티스는
파드의 오토스케일링
도 지원하지만 본 튜토리얼에서는 다루지 않는다. 0까지 스케일링하는 것도 가능하다. 이 경우 해당
디플로이먼트의 모든 파드가 종료된다.
애플리케이션의 인스턴스를 복수로 구동하게 되면 트래픽을 해당 인스턴스 모두에 분산시킬 방법이
필요해진다. 서비스는 노출된 디플로이먼트의 모든 파드에 네트워크 트래픽을 분산시켜줄 통합된
로드밸런서를 갖는다. 서비스는 엔드포인트를 이용해서 구동중인 파드를 지속적으로 모니터링함으로써
가용한 파드에만 트래픽이 전달되도록 해준다.
디플로이먼트의 복제 수를 변경하면 스케일링이 수행된다.
일단 복수의 애플리케이션의 인스턴스가 구동 중이면, 다운타임 없이 롤링 업데이트를 할 수 있다.
다음 모듈에서 이 내용을 다루도록 하겠다. 이제 온라인 터미널로 가서 애플리케이션을 스케일해보자.
사용자들은 애플리케이션이 항상 가용한 상태일 것이라 여기고 개발자들은 하루에 여러번씩 새로운 버전을
배포하도록 요구 받고있다. 쿠버네티스에서는 이것을 롤링 업데이트를 통해 이루고 있다. 롤링 업데이트는 파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 해준다.
새로운 파드는 가용한 자원을 보유한 노드로 스케줄될 것이다.
이전 모듈에서 여러 개의 인스턴스를 동작시키도록 애플리케이션을 스케일했다. 이것은 애플리케이션의 가용성에 영향을 미치지 않으면서
업데이트를 수행하는 것에 대한 요구이다. 기본적으로, 업데이트가 이루어지는 동안 이용 불가한 파드의 최대 개수와 생성 가능한 새로운 파드의 최대 개수는 하나다.
두 옵션은 (파드에 대한) 개수 또는 백분율로 구성될 수 있다.
쿠버네티스에서, 업데이트는 버전으로 관리되고 어떠한 디플로이먼트 업데이트라도 이전의 (안정적인) 버전으로 원복이 가능하다.
요약:
앱 업데이트하기
롤링 업데이트는 파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 해준다.
5.3.1.1 - MicroProfile, 컨피그맵(ConfigMaps) 및 시크릿(Secrets)을 사용하여 구성 외부화(externalizing)
이 튜토리얼에서는 마이크로서비스의 구성을 외부화하는 방법과 이유를 알아본다. 특히, 쿠버네티스 컨피그맵과 시크릿을 사용하여 환경 변수를 설정한 다음 MicroProfile Config를 이용한 사용 방법을 배운다.
시작하기 전에
쿠버네티스 컨피그맵 및 시크릿 생성하기
쿠버네티스에서 도커 컨테이너에 대한 환경 변수를 설정하는 방법에는 Dockerfile, kubernetes.yml, 쿠버네티스 컨피그맵 및 쿠버네티스 시크릿이 있다. 이 튜토리얼에서는 사용자의 마이크로서비스에 값을 주입하기 위한 환경 변수를 설정하기 위해 후자의 두 가지를 사용하는 방법에 대해 배운다. 컨피그맵 및 시크릿을 사용할 때의 이점 중 하나는 여러 다른 컨테이너에 대해 서로 다른 환경 변수에 할당되는 것을 포함하여, 여러 컨테이너에서 다시 사용할 수 있다는 것이다.
컨피그맵은 기밀이 아닌 키-값 쌍을 저장하는 API 오브젝트이다. 대화형 튜토리얼에서는 컨피그맵을 사용하여 애플리케이션의 이름을 저장하는 방법을 배운다. 컨피그맵에 대한 자세한 정보는 여기에서 문서를 찾을 수 있다.
시크릿은 키-값 쌍을 저장하는 데도 사용되지만, 기밀/민감한 정보를 위한 것이며 Base64 인코딩을 사용하여 저장된다는 점에서 컨피그맵과 다르다. 따라서 시크릿은 자격 증명, 키 및 토큰과 같은 항목을 저장하는 데 적합한 선택이 된다. 이 내용은 대화형 튜토리얼에서 수행할 것이다. 시크릿에 대한 자세한 내용은 여기에서 문서를 찾을 수 있다.
코드로부터 구성 외부화
구성은 일반적으로 환경에 따라 변경되기 때문에, 외부화된 애플리케이션 구성(externalized application configuration)은 유용하다. 이를 이루기 위해, Java의 CDI(콘텍스트와 의존성 주입) 및 MicroProfile Config를 사용한다. MicroProfile Config는 클라우드 네이티브 마이크로서비스를 개발하고 배포하기 위한 개방형 Java 기술 세트인 MicroProfile의 기능이다.
CDI는 느슨하게 결합된 협업 빈(beans)을 통해 애플리케이션을 어셈블할 수 있는 표준 종속성 주입(standard dependency injection) 기능을 제공한다. MicroProfile Config는 애플리케이션, 런타임 및 환경을 포함한 다양한 소스에서 구성 속성을 가져오는 표준 방법을 앱과 마이크로서비스에 제공한다. 소스의 정의된 우선순위에 따라 속성은 애플리케이션이 API를 통해 접근할 수 있는 단일 속성 집합으로 자동 결합된다. 대화형 튜토리얼에서는 CDI와 MicroProfile을 함께 사용하여 쿠버네티스 컨피그맵 및 시크릿을 통한 외부 제공 속성을 검색하고 애플리케이션 코드에 삽입한다.
많은 오픈 소스 프레임워크와 런타임이 MicroProfile Config를 구현하고 지원한다. 대화형 튜토리얼을 통해 클라우드 네이티브 앱과 마이크로서비스를 빌드하고 실행하기 위한 유연한 오픈 소스 Java 런타임인 Open Liberty를 사용하게 될 것이다. 그러나, 모든 MicroProfile 호환 런타임을 대신 사용할 수 있다.
서비스에 의해 노출된 외부 IP 주소 (LoadBalancer Ingress)를 기억해두자.
예시에서 외부 IP 주소는 104.198.205.71이다.
그리고 Port와NodePort의 값을 기억해두자.
예시에서 Port는 8080이고 NodePort는 32377이다.
위의 출력 결과를 통해, 서비스에 여러 엔드포인트가 있음을 알 수 있다.
10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2.
이 주소는 Hello World 애플리케이션을 실행 중인 파드의 내부 주소다.
해당 주소가 파드 주소인지 확인하려면, 아래 명령어를 입력하면 된다.
Hello World 애플리케이션에 접근하기 위해
외부 IP 주소 (LoadBalancer Ingress)를 사용한다.
curl http://<external-ip>:<port>
<external-ip>는 서비스의 외부 IP 주소 (LoadBalancer Ingress)를 의미하며,
<port>는 서비스 정보에서 Port 값을
의미한다.
만약 minikube를 사용하고 있다면, minikube service my-service 명령어를 통해,
자동으로 브라우저 내에서 Hello World 애플리케이션에 접근할 수 있다.
성공적인 요청에 대한 응답으로 hello 메세지가 나타난다.
Hello Kubernetes!
정리하기
서비스를 삭제하려면, 아래의 명령어를 입력한다.
kubectl delete services my-service
Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카셋, 파드를 삭제하려면,
아래의 명령어를 입력한다.
kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend
결과는 아래와 같은 형태로 나타난다.
NAME READY STATUS RESTARTS AGE
frontend-3823415956-dsvc5 1/1 Running 0 54s
frontend-3823415956-k22zn 1/1 Running 0 54s
frontend-3823415956-w9gbt 1/1 Running 0 54s
프론트엔드 서비스 생성하기
서비스의 기본 유형은 ClusterIP이기 때문에 적용한 mongo 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. ClusterIP는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다.
게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 쿠버네티스 클러스터 외부에서 서비스를 요청할 수 있다. 그러나 쿠버네티스 사용자는 ClusterIP를 사용하더라도 kubectl port-forward를 사용해서 서비스에 접근할 수 있다.
참고: Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 type : LoadBalancer의 주석을 제거해야 한다.
apiVersion:v1kind:Servicemetadata:name:frontendlabels:app.kubernetes.io/name:guestbookapp.kubernetes.io/component:frontendspec:# if your cluster supports it, uncomment the following to automatically create# an external load-balanced IP for the frontend service.# type: LoadBalancerports:- port:80selector:app.kubernetes.io/name:guestbookapp.kubernetes.io/component:frontend
참고: 이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록
설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면,
튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을
프로비저닝해야 한다.
목적
스테이트풀셋은 상태 유지가 필요한(stateful) 애플리케이션과 분산시스템에서
이용하도록 의도했다. 그러나 쿠버네티스 상에 스테이트풀 애플리케이션과
분산시스템을 관리하는 것은 광범위하고 복잡한 주제이다. 스테이트풀셋의 기본 기능을 보여주기 위해
이 둘을 결합하지 않고, 스테이트풀셋을 사용한
단순 웹 애플리케이션을 배포할 것이다.
이 튜토리얼을 마치면 다음 항목에 대해 익숙해질 것이다.
스테이트풀셋을 어떻게 생성하는지
스테이트풀셋이 어떻게 파드를 관리하는지
스테이트풀셋을 어떻게 삭제하는지
스테이트풀셋은 어떻게 스케일링하는지
스테이트풀셋의 파드는 어떻게 업데이트하는지
스테이트풀셋 생성하기
아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는
스테이트풀셋 개념에서 보인
예제와 유사하다. 이것은 web과 이 스테이트풀셋 파드의 IP 주소를 게시하는
헤드리스 서비스인
nginx 를 생성한다.
참고로 web-1 파드는 web-0 파드가 Running (파드의 단계 참고)
및 Ready (파드의 조건에서 type 참고) 상태가 되기 전에 시작하지 않음을 주의하자.
스테이트풀셋 안에 파드
스테이트풀셋 안에 파드는 고유한 순번과 동일한 네트워크 신원을 가진다.
파드 순번 살펴보기
스테이트풀셋의 파드를 가져오자.
kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 1m
web-1 1/1 Running 0 1m
스테이트풀셋 개념에서
언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다.
이 정체성은 스테이트풀셋 컨트롤러에서
각 파드에 주어지는 고유한 순번에 기인한다. 파드의 이름의 형식은
<스테이트풀셋 이름>-<순번> 이다. 앞서 web 스테이트풀셋은
2개의 레플리카를 가졌으므로 web-0 과 web-1 2개 파드를 생성한다.
안정적인 네트워크 신원 사용하기
각 파드는 각 순번에 따른 안정적인 호스트네임을 갖는다. 각 파드에서
hostname 명령어를 실행하도록
kubectl exec를 이용하자.
for i in 0 1; do kubectl exec"web-$i" -- sh -c 'hostname'; done
web-0
web-1
dnsutils 패키지에서 nslookup 명령을 제공하는 컨테이너를
실행하도록 kubectl run을 이용하자.
파드의 호스트네임에 nslookup을 이용하면 클러스터 내부 DNS 주소를
확인할 수 있다.
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm
위 명령으로 새로운 셸을 시작한다. 새 셸에서 다음을 실행한다.
# dns-test 컨테이너 셸에서 다음을 실행한다.
nslookup web-0.nginx
파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만
파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나
다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로
스테이트풀셋의 파드에 접속하지 않도록 하는 것이 중요하다.
스테이트풀셋의 활성 멤버를 찾아 연결할 경우
헤드리스 서비스(nginx.default.svc.cluster.local)의 CNAME을 쿼리해야 한다.
CNAME과 연관된 SRV 레코드는 스테이트풀셋의
Running과 Ready 상태의 모든 파드들을
담고 있다.
애플리케이션에서 이미 활성상태(liveness)와 준비성(readiness) 테스트하는
연결 로직을 구현되어 있다면
파드web-0.nginx.default.svc.cluster.local,
web-1.nginx.default.svc.cluster.local)의 SRV레코드를 안정적으로 사용할 수 있어
애플리케이션은 파드가 Running과 Ready 상태로 전환할 때
파드의 주소를 검색할 수 있다.
안정적인 스토리지에 쓰기
web-0과 web-1에 대해 퍼시스턴트볼륨클레임(PersistentVolumeClaim)을 가져오자.
kubectl get pvc -l app=nginx
출력 결과는 다음과 비슷하다.
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
for i in 0 1; do kubectl exec"web-$i" -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; donefor i in 0 1; do kubectl exec -it "web-$i" -- curl localhost; done
web-0
web-1
참고:
위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면
다음을 실행해서 volumeMounts로 마운트된 디렉터리의 퍼미션을 수정해야 한다
(hostPath 볼륨을 사용할 때에 버그로 인함).
for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done
위에 curl 명령을 재시도하기 전에 위 명령을 실행해야 한다.
첫째 터미널에서 스테이트풀셋의 파드를 감시하자.
kubectl get pod -w -l app=nginx
두 번째 터미널에서 스테이트풀셋의 모든 파드를 삭제하자.
kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
첫 번째 터미널에서 실행 중인 kubectl get명령어의 출력을 확인하고,
모든 파드가 Running과 Ready 상태로 전환될 때까지 기다리자.
kubectl get pod -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 0/1 ContainerCreating 0 0s
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 2s
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 34s
웹서버에서 자신의 호스트네임을 계속 제공하는지 확인하자.
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1
비록 web-0과 web-1이 재스케줄링되어도 계속해서
자신의 호스트네임을 제공하는데 이는 각 퍼시스턴트볼륨클레임에
연관된 퍼시스턴트볼륨이 해당 volumeMounts로 재마운트되기 때문이다.
web-0과 web-1의 스케줄링에 관계없이
각각의 퍼시스턴트볼륨은 적절하게 마운트된다.
스테이트풀셋 스케일링
스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 replicas 필드를 갱신하여 이뤄진다.
kubectl scale이나
kubectl patch을
이용해서 스테이트풀셋을 스케일링할 수 있다.
스케일 업
터미널창에서 스테이트풀셋의 파드를 감시하자.
kubectl get pods -w -l app=nginx
다른 터미널창에서 kubectl scale을 이용하여 레플리카 개수를
5로 스케일링하자.
kubectl scale sts web --replicas=5
statefulset.apps/web scaled
첫 번째 터미널에서 실행 중인 kubectl get명령어의 출력을 확인하고,
3개의 추가 파드가 Running과 Ready 상태로 전환될 때까지 기다리자.
여전히 5개의 퍼시스턴트볼륨클레임과 5개의 퍼시스턴트볼륨이 있다.
파드의 안전한 스토리지를 탐색하면서 스테이트풀셋의 파드가 삭제될 때에 파드에 마운트된 스테이트풀셋의 퍼시스턴트볼륨이 삭제되지 않은 것을 보았다. 스테이트풀셋 스케일 다운으로 파드 삭제할 때에도 여전히 사실이다.
스테이트풀셋 업데이트하기
쿠버네티스 1.7 이상에서 스테이트풀셋 컨트롤러는 자동 업데이트를 지원한다.
전략은 스테이트풀셋 API 오브젝트의 spec.updateStrategy 필드로 결정된다.
이 기능은 컨테이너 이미지, 스테이트풀셋의 리소스 요청이나
혹은 한계와 레이블과 파드의 어노테이션을 업그레이드하기 위해 사용될 수 있다.
RollingUpdate과 OnDelete의 2개의
유효한 업데이트 전략이 있다.
RollingUpdate 업데이트 전략은 스테이트풀셋에서 기본 값이다.
롤링 업데이트
RollingUpdate 업데이트 전략은 스테이트풀셋을 보장하면서 스테이트풀셋 내에 파드를 역순으로 업데이트합니다.
스테이트풀셋 web의 업데이트 전략을 RollingUpdate으로 패치하자.
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
statefulset.apps/web patched
터미널 창에서 스테이트풀셋 web의 컨테이너 이미지를 바꾸도록
또 패치하자.
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]'
스테이트풀셋 내에 파드는 순번의 역순으로 업데이트된다.
이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에
그것이 Running과 Ready 상태로 전환될 때까지 기다린다.
알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지
다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면
복원한다는 것이다.
업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는
이전 버전으로 복원한다. 이런 식으로 컨트롤러는 간헐적인 오류가 발생해도
애플리케이션을 계속 건강하게 유지하고
업데이트도 일관되게 유지하려 한다.
컨테이너 이미지를 살펴보기 위해 파드를 가져오자.
for p in 01 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
k8s.gcr.io/nginx-slim:0.8
web-1 는 원래 환경설정으로 복원되었는데
이는 파드의 순번이 partition보다 작기 때문이다.
스테이트풀셋의 .spec.template이 갱신되면, 지정된 partition 이상의 순번을
가진 모든 파드는 업데이트된다. 미만의 순번을 가진 파드라면 삭제되거나
종료되어 원래 환경설정으로 복원된다.
단계적 롤아웃
카나리 롤아웃에서 했던 방법과 비슷하게
분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을
수행할 수 있다. 단계적 롤아웃을 수행하려면
컨트롤러가 업데이트를 일시 중지할 순번으로
partition를 정하자.
partition은 현재 2이다. partition을 0으로 바꾸자.
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}'
partition을 0으로 이동하여 스테이트풀셋에서 계속해서
업데이트 처리를 하도록 허용하였다.
삭제 시 동작
OnDelete 업데이트 전략은 예전 동작(1.6 이하)으로,
이 업데이트 전략을 선택하면 스테이트풀셋 컨트롤러는 스테이트풀셋의
.spec.template 필드에 수정 사항이 발생해도 자동으로 파드를 업데이트하지 않는다.
이 전략은 .spec.template.updateStrategy.type을 OnDelete로 설정하여 선택할 수 있다.
스테이트풀셋 삭제하기
스테이트풀셋은 비종속적(non-cascading), 종속적(cascading) 삭제를 둘 다 지원한다.
비종속적 삭제에서는 스테이트풀셋이 지워질 때에 스테이트풀셋의 파드는 지워지지 않는다.
종속적 삭제에서는 스테이트풀셋과 그에 속한 파드가 모두 지워진다.
비종속적 삭제
터미널창에서 스테이트풀셋의 파드를 감시하자.
kubectl get pods -w -l app=nginx
다른 터미널에서는 스테이트풀셋을 지우기 위해
kubectl delete 명령어를 이용하자.
이 명령어에 --cascade=false 파라미터가 추가되었다.
이 파라미터는 쿠버네티스에 스테이트풀셋만 삭제하고 그에 속한 파드는 지우지 않도록 요청한다.
kubectl delete statefulset web --cascade=false
statefulset.apps "web" deleted
상태를 확인하기 위해 파드를 가져오자.
kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 6m
web-1 1/1 Running 0 7m
web-2 1/1 Running 0 5m
비록 web이 삭제되고 있어도, 모든 파드는 여전히 Running과 Ready 상태이다.
web-0을 삭제하자.
kubectl delete pod web-0
pod "web-0" deleted
스테이트풀셋의 파드를 가져오자.
kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
web-1 1/1 Running 0 10m
web-2 1/1 Running 0 7m
스테이트풀셋 web이 삭제되는 동안 web-0은 재시작하지 않았다.
첫째 터미널에서 스테이트풀셋의 파드를 감시하자.
kubectl get pods -w -l app=nginx
두 번째 터미널에서 스테이트풀셋을 다시 생성하자.
nginx 서비스(가지지 말았어야 하는)를 삭제하기 전까지는 그 서비스가 이미 존재한다는 에러를
볼 것이라는 것을 명심하자.
kubectl apply -f web.yaml
statefulset.apps/web created
service/nginx unchanged
이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도
nginx 헤드리스 서비스를 생성하려고 했음을 뜻한다.
첫째 터미널에서 실행 중인 kubectl get 명령어의 출력을 살펴보자.
kubectl get pods -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-1 1/1 Running 0 16m
web-2 1/1 Running 0 2m
NAME READY STATUS RESTARTS AGE
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 18s
web-2 1/1 Terminating 0 3m
web-2 0/1 Terminating 0 3m
web-2 0/1 Terminating 0 3m
web-2 0/1 Terminating 0 3m
web 스테이트풀셋이 다시 생성될 때 먼저 web-0 시작한다.
web-1은 이미 Running과 Ready 상태이므로 web-0이 Running과 Ready 상태로
전환될 때는 이 파드에 적용됐다. 스테이트풀셋에 replicas를 2로 하고
web-0을 재생성했다면 web-1이
이미 Running과 Ready 상태이고,
web-2은 종료되었을 것이다.
파드의 웹서버에서 제공한 index.html 파일 내용을
다른 관점으로 살펴보자.
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1
스테이트풀셋과 web-0 파드를 둘 다 삭제했으나 여전히 index.html 파일에 입력했던
원래 호스트네임을 제공한다. 스테이트풀셋은
파드에 할당된 퍼시스턴트볼륨을 결코 삭제하지 않기때문이다.
다시 스테이트풀셋을 생성하면 web-0을 시작하며
원래 퍼시스턴트볼륨을 다시 마운트한다.
단계식 삭제
터미널창에서 스테이트풀셋의 파드를 감시하자.
kubectl get pods -w -l app=nginx
다른 터미널창에서 스테이트풀셋을 다시 지우자. 이번에는
--cascade=false 파라미터를 생략하자.
kubectl delete statefulset web
statefulset.apps "web" deleted
첫째 터미널에서 실행 중인 kubectl get 명령어의 출력을 살펴보고
모든 파드가 Terminating 상태로 전환될 때까지 기다리자.
kubectl get pods -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 11m
web-1 1/1 Running 0 27m
NAME READY STATUS RESTARTS AGE
web-0 1/1 Terminating 0 12m
web-1 1/1 Terminating 0 29m
web-0 0/1 Terminating 0 12m
web-0 0/1 Terminating 0 12m
web-0 0/1 Terminating 0 12m
web-1 0/1 Terminating 0 29m
web-1 0/1 Terminating 0 29m
web-1 0/1 Terminating 0 29m
스케일 다운 섹션에서 보았듯 파드는
각 순번의 역순으로 하나씩 종료된다. 파드가 종료될 때
스테이트풀 컨트롤러는 이전 파드가
완전히 종료되기까지 기다린다.
참고: 종속적 삭제는 파드와 함께 스테이트풀셋을 제거하지만,
스테이트풀셋과 관련된 헤드리스 서비스를 삭제하지 않는다.
꼭 nginx 서비스를 수동으로 삭제해라.
kubectl delete service nginx
service "nginx" deleted
스테이트풀셋과 헤드리스 서비스를 한번 더 다시 생성하자.
kubectl apply -f web.yaml
service/nginx created
statefulset.apps/web created
스테이트풀셋의 모든 파드가 Running과 Ready 상태로 전환될 때
index.html 파일 내용을 검색하자.
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1
스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로
다시 생성되고 web-0과 web-1은 계속
각 호스트네임을 제공한다.
최종적으로 nginx 서비스를 삭제한다.
kubectl delete service nginx
service "nginx" deleted
그리고 web 스테이트풀셋을 삭제한다.
kubectl delete statefulset web
statefulset "web" deleted
파드 관리 정책
일부 분산 시스템의 경우 스테이트풀셋의 순서 보증은
불필요하거나 바람직하지 않다. 이러한 시스템은 고유성과 신원만 필요하다.
이를 해결하기 위해 쿠버네티스 1.7에서 .spec.podManagementPolicy를
스테이트풀셋 API 오브젝트에 도입했다.
OrderedReady 파드 관리
OrderedReady 파드 관리는 스테이트풀셋에서는 기본이다.
이는 스테이트풀셋 컨트롤러가 지금까지 위에서 설명했던 순서를
보증함을 뜻한다.
Parallel 파드 관리
Parallel 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를
병렬로 시작하고 종료하는 것으로, 다른 파드를 시작/종료하기 전에
파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지
기다리지 않음을 뜻한다.
이 옵션은 스케일링 동작에만 영향을 미치며, 업데이트 동작에는 영향을 미치지 않는다.
삭제하는 동안, 스테이트풀셋은 모든 파드를 동시에 삭제한다. 해당 파드를 삭제하기 전에
그 파드의 순서상 후계자를 기다리지 않는다.
kubectl get 명령어가 실행된 터미널을 닫고
nginx 서비스를 삭제하자.
kubectl delete svc nginx
참고:
이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한
퍼시스턴트 스토리지 미디어도 삭제해야 한다.
모든 스토리지를 반환하도록 환경, 스토리지 설정과
프로비저닝 방법에 따른 단계를 따르자.
5.5.2 - 예시: WordPress와 MySQL을 퍼시스턴트 볼륨에 배포하기
이 튜토리얼은 WordPress 사이트와 MySQL 데이터베이스를 Minikube를 이용하여 어떻게 배포하는지 보여준다. 애플리케이션 둘 다 퍼시스턴트 볼륨과 퍼시스턴트볼륨클레임을 데이터를 저장하기 위해 사용한다.
퍼시스턴트볼륨(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 스토리지클래스를 이용해 동적으로 프로비저닝된 저장소의 일부이다. 퍼시스턴트볼륨클레임(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다.
경고: 이 배포는 프로덕션 사용 예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 WordPress Helm Chart로 배포하기를 고려해보자.
참고: 이 튜토리얼에 제공된 파일들은 GA 디플로이먼트 API를 사용하며 쿠버네티스 버전 1.9 이상을 이용한다. 이 튜토리얼을 쿠버네티스 하위 버전에서 적용한다면 API 버전을 적절히 갱신하거나 이 튜토리얼의 이전 버전을 참고하자.
목적
퍼시스턴트볼륨클레임과 퍼시스턴트볼륨 생성
다음을 포함하는 kustomization.yaml 생성
시크릿 생성자
MySQL 리소스 구성
WordPress 리소스 구성
kubectl apply -k ./로 생성한 kustomization 을 적용
정리
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
통신할 수 있도록 설정되어 있어야 한다.
만약, 아직 클러스터를 가지고 있지 않다면,
minikube를 사용해서 생성하거나
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
MySQL과 Wordpress는 각각 데이터를 저장할 퍼시스턴트볼륨이 필요하다. 퍼시스턴트볼륨클레임은 배포 단계에 생성된다.
많은 클러스터 환경에서 설치된 기본 스토리지클래스(StorageClass)가 있다. 퍼시스턴트볼륨클레임에 스토리지클래스를 지정하지 않으면 클러스터의 기본 스토리지클래스를 사용한다.
퍼시스턴트볼륨클레임이 생성되면 퍼시스턴트볼륨이 스토리지클래스 설정을 기초로 동적으로 프로비저닝된다.
경고: 로컬 클러스터에서 기본 스토리지클래스는 hostPath 프로비저너를 사용한다. hostPath는 개발과 테스트 목적에만 적합하다. hostPath 볼륨인 경우 데이터는 스케쥴링된 파드의 노드에 /tmp 살아있고 노드 간에 이동하지 않는다. 파드가 죽어서 클러스터 내에 다른 노드로 스케줄링되거나 해당 노드가 재부팅되면 그 데이터는 잃어버린다.
참고:hostPath 프로비저너를 사용해야 하는 클러스터를 기동하는 경우라면 --enable-hostpath-provisioner 플래그를 controller-manager 컴포넌트에 꼭 설정해야 한다.
참고: 만약 구글 쿠버네티스 엔진으로 운영하는 쿠버네티스 클러스터를 가지고 있다면 가이드를 따르도록 한다.
kustomization.yaml 생성하기
시크릿 생성자 추가
시크릿은 암호나 키 같은 민감한 데이터들을 저장하는 오브젝트이다. 1.14 버전부터 kubectl은 kustomization 파일을 이용해서 쿠버네티스 오브젝트를 관리한다. kustomization.yaml의 제너레이터로 시크릿을 생성할 수 있다.
다음 명령어로 kustomization.yaml 내에 시크릿 제네레이터를 추가한다. YOUR_PASSWORD는 사용하기 원하는 암호로 변경해야 한다.
다음의 매니페스트는 단일-인스턴스 WordPress 디플로이먼트를 기술한다. WordPress 컨테이너는
웹사이트 데이터 파일을 위해 /var/www/html에 퍼시스턴트볼륨을 마운트한다. WORDPRESS_DB_HOST 환경 변수에는
위에서 정의한 MySQL 서비스의 이름이 설정되며, WordPress는 서비스를 통해 데이터베이스에 접근한다.
WORDPRESS_DB_PASSWORD 환경 변수에는 kustomize가 생성한 데이터베이스 패스워드가 설정된다.
kustomization.yaml은 WordPress 사이트와 MySQL 데이터베이스를 배포하는 모든 리소스를 포함한다.
다음과 같이 디렉터리를 적용할 수 있다.
kubectl apply -k ./
이제 모든 오브젝트가 존재하는지 확인할 수 있다.
시크릿이 존재하는지 다음 명령어를 실행하여 확인한다.
kubectl get secrets
응답은 아래와 비슷해야 한다.
NAME TYPE DATA AGE
mysql-pass-c57bb4t7mf Opaque 1 9s
퍼시스턴트볼륨이 동적으로 프로비저닝되었는지 확인한다.
kubectl get pvc
참고: PV를 프로비저닝하고 정착(bound)시키는데 수 분이 걸릴 수 있다.
응답은 아래와 비슷해야 한다.
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
다음 명령어를 실행하여 파드가 실행 중인지 확인한다.
kubectl get pods
참고: 파드의 상태가 RUNNING가 되기까지 수 분이 걸릴 수 있다.
응답은 아래와 비슷해야 한다.
NAME READY STATUS RESTARTS AGE
wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s
다음 명령어를 실행하여 서비스가 실행 중인지 확인해보자.
kubectl get services wordpress
응답은 아래와 비슷해야 한다.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
wordpress LoadBalancer 10.0.0.89 <pending> 80:32406/TCP 4m
참고: Minikube에서는 서비스를 NodePort으로만 노출할 수 있다. EXTERNAL-IP는 항상 Pending 상태이다.
다음 명령어를 실행하여 WordPress 서비스의 IP 주소를 얻어온다.
minikube service wordpress --url
응답은 아래와 비슷해야 한다.
http://1.2.3.4:32406
IP 주소를 복사해서 웹 브라우저에서 사이트를 열어 보자.
아래 스크린샷과 유사한 WordPress 설정 페이지를 볼 수 있어야 한다.
경고: 이 페이지의 WordPress 설치를 내버려 두지 말자. 다른 사용자가 이 페이지를 발견하고 귀하의 인스턴스에 웹 사이트를 설정하고 악의적인 컨텐츠를 게시하는데 사용할 수 있다.
이 튜토리얼은 쿠버네티스에서 아파치 카산드라를 실행하는 방법을 소개한다.
데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 상태).
이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다.
스테이트풀셋 은 상태있는 애플리케이션을 쿠버네티스 클러스터에 쉽게 배포할 수 있게 한다.
이 튜토리얼에서 이용할 기능의 자세한 정보는
스테이트풀셋을 참조한다.
참고:
카산드라와 쿠버네티스는 클러스터 맴버라는 의미로 노드 라는 용어를 사용한다. 이
튜토리얼에서 스테이트풀셋에 속하는 파드는 카산드라 노드이며 카산드라
클로스터의 맴버(링 이라 함)이다. 해당 파드가 쿠버네티스 클러스터에서 실행될 때,
쿠버네티스 컨트롤 플레인은 해당 파드를 쿠버네티스
노드에 스케줄 한다.
카산드라 노드가 시작되면 시드 목록 을 사용해서 링에 있는 다른 노드 검색을 위한
위한 부트스트랩을 한다.
이 튜토리얼에는 데이터베이스가 쿠버네티스 클러스터 내부에 나타날 때 새로운 카산드라
파드를 검색할 수 있는 사용자 지정 카산드라 시드 공급자를 배포한다.
apiVersion:apps/v1kind:StatefulSetmetadata:name:cassandralabels:app:cassandraspec:serviceName:cassandrareplicas:3selector:matchLabels:app:cassandratemplate:metadata:labels:app:cassandraspec:terminationGracePeriodSeconds:1800containers:- name:cassandraimage:gcr.io/google-samples/cassandra:v13imagePullPolicy:Alwaysports:- containerPort:7000name:intra-node- containerPort:7001name:tls-intra-node- containerPort:7199name:jmx- containerPort:9042name:cqlresources:limits:cpu:"500m"memory:1Girequests:cpu:"500m"memory:1GisecurityContext:capabilities:add:- IPC_LOCKlifecycle:preStop:exec:command:- /bin/sh- -c- nodetool drainenv:- name:MAX_HEAP_SIZEvalue:512M- name:HEAP_NEWSIZEvalue:100M- name:CASSANDRA_SEEDSvalue:"cassandra-0.cassandra.default.svc.cluster.local"- name:CASSANDRA_CLUSTER_NAMEvalue:"K8Demo"- name:CASSANDRA_DCvalue:"DC1-K8Demo"- name:CASSANDRA_RACKvalue:"Rack1-K8Demo"- name:POD_IPvalueFrom:fieldRef:fieldPath:status.podIPreadinessProbe:exec:command:- /bin/bash- -c- /ready-probe.shinitialDelaySeconds:15timeoutSeconds:5# These volume mounts are persistent. They are like inline claims,# but not exactly because the names need to match exactly one of# the stateful pod volumes.volumeMounts:- name:cassandra-datamountPath:/cassandra_data# These are converted to volume claims by the controller# and mounted at the paths mentioned above.# do not use these in production until ssd GCEPersistentDisk or other ssd pdvolumeClaimTemplates:- metadata:name:cassandra-dataspec:accessModes:["ReadWriteOnce"]storageClassName:fastresources:requests:storage:1Gi---kind:StorageClassapiVersion:storage.k8s.io/v1metadata:name:fastprovisioner:k8s.io/minikube-hostpathparameters:type:pd-ssd
cassandra-statefulset.yaml 파일로 카산드라 스테이트풀셋 생성
# cassandra-statefulset.yaml을 수정하지 않은 경우에 이것을 사용한다.
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
Datacenter: DC1-K8Demo
======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 172.17.0.5 83.57 KiB 32 74.0% e2dd09e6-d9d3-477e-96c5-45094c08db0f Rack1-K8Demo
UN 172.17.0.4 101.04 KiB 32 58.8% f89d6835-3a42-4419-92b3-0e62cae1479c Rack1-K8Demo
UN 172.17.0.6 84.74 KiB 32 67.1% a6a1e8c2-3dc5-4417-b1a0-26507af2aaad Rack1-K8Demo
카산드라 스테이트풀셋 수정하기
kubectl edit를 사용하여 카산드라 스테이트풀셋의 크기를 수정한다.
다음 명령어를 실행한다.
kubectl edit statefulset cassandra
이 명령은 터미널에서 편집기를 연다. 변경해야할 행은 replicas 필드이다.
다음 예제는 스테이트풀셋 파일에서 발췌했다.
# 다음의 오브젝트를 수정한다. '#'로 시작하는 행은 무시되고,# 빈 파일은 편집을 중단한다. 저장할 때 오류가 발생하면 이 파일이# 관련 실패와 함께 다시 열린다.#apiVersion:apps/v1kind:StatefulSetmetadata:creationTimestamp:2016-08-13T18:40:58Zgeneration:1labels:app:cassandraname:cassandranamespace:defaultresourceVersion:"323"uid:7a219483-6185-11e6-a910-42010a8a0fc0spec:replicas:3
레플리카 개수를 4로 바꾸고, 매니페스트를 저장한다.
스테이트풀셋은 4개의 파드를 실행하기 위해 스케일 한다.
검증하기 위해 카산드라 스테이트풀셋을 살펴보자
kubectl get statefulset cassandra
결과는 다음과 유사하다.
NAME DESIRED CURRENT AGE
cassandra 4 4 36m
정리하기
스테이트풀셋을 삭제하거나 스케일링하는 것은 스테이트풀셋에 연관된 볼륨을 삭제하지 않는다.
당신의 데이터가 스테이트풀셋의 관련된 모든 리소스를 자동으로 제거하는 것보다 더 가치있기에 이 설정은 당신의 안전을 위한 것이다.
경고: 스토리지 클래스와 리클레임 정책에 따라 퍼시스턴스볼륨클레임 을 삭제하면 그와 연관된 볼륨도
삭제될 수 있다. 볼륨 요청이 삭제되어도 데이터를 접근할 수 있다고 절대로 가정하지 말자.
반드시 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. 이것은 클러스터를 종료하여 노드의 모든 파드를 축출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다. 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.
이 튜토리얼은 클러스터가 동적으로 퍼시스턴트볼륨을 프로비저닝하도록 구성한다고 가정한다.
그렇게 설정되어 있지 않다면
튜토리얼을 시작하기 전에 수동으로 3개의 20 GiB 볼륨을
프로비저닝해야 한다.
목적
이 튜토리얼을 마치면 다음에 대해 알게 된다.
어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가.
어떻게 앙상블을 일관되게 설정하는가.
어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
ZooKeeper
아파치 ZooKeeper는
분산 애플리케이션을 위한 분산 오픈 소스 코디네이션 서비스이다.
ZooKeeper는 데이터를 읽고 쓰고 갱신을 지켜보도록 한다. 데이터는
파일시스템처럼 계층적으로 관리되고 앙상블(ZooKeeper 서버의 집합) 내에 모든 ZooKeeper서버에 복제된다.
데이터에 모든 연산은 원자적이고 순처적으로 일관된다. ZooKeeper는
Zab 합의 프로토콜을
이용하여 앙상블 내에 모든 서버에 걸쳐 상태 머신을 복제하여 이를 보장한다.
앙상블은 리더 선출을 위해 Zab 프로토콜을 사용하고, 리더 선출과 선거가 완료되기 전까지 앙상블은 데이터를 쓸 수 없다. 완료되면 앙상블은 Zab을 이용하여 확인하고 클라이언트에 보이도록 모든 쓰기를 쿼럼(quorum)에 복제한다. 가중치있는 쿼럼과 관련 없이, 쿼럼은 현재 리더를 포함하는 앙상블의 대다수 컴포넌트이다. 예를 들어 앙상블이 3개 서버인 경우, 리더와 다른 서버로 쿼럼을 구성한다. 앙상블이 쿼럼을 달성할 수 없다면, 앙상블은 데이터를 쓸 수 없다.
ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변이를 저장 미디어의 내구성 있는 WAL(Write Ahead Log)에 기록한다. 서버 장애시 WAL을 재생하여 이전 상태를 복원할 수 있다. WAL이 무제한으로 커지는 것을 방지하기 위해 ZooKeeper는 주기적으로 저장 미디어에 메모리 상태의 스냅샷을 저장한다. 이 스냅샷은 메모리에 직접 적재할 수 있고 스냅샷 이전의 모든 WAL 항목은 삭제될 수 있다.
for i in 01 2; do kubectl exec zk-$i -- hostname; done
스테이트풀셋 컨트롤러는 각 순번 인덱스에 기초하여 각 파드에 고유한 호스트네임을 부여한다. 각 호스트네임은 <스테이트풀셋 이름>-<순번 인덱스> 형식을 취한다. zk 스테이트풀셋의 replicas 필드는 3으로 설정되었기 때문에, 그 스테이트풀셋 컨트롤러는 3개 파드의 호스트네임을 zk-0, zk-1,
zk-2로 정한다.
zk-0
zk-1
zk-2
ZooKeeper 앙상블에 서버들은 고유 식별자로서 자연수를 이용하고 서버 데이터 디렉터리에 my 라는 파일로 서버 식별자를 저장한다.
각 서버에서 다음 명령어를 이용하여 myid 파일의 내용을 확인하자.
for i in 01 2; doecho"myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeeper/data/myid; done
식별자는 자연수이고, 순번 인덱스들도 음수가 아니므로, 순번에 1을 더하여 순번을 만들 수 있다.
myid zk-0
1
myid zk-1
2
myid zk-2
3
zk 스테이트풀셋의 각 파드 Fully Qualified Domain Name (FQDN)을 얻기 위해 다음 명령어를 이용하자.
for i in 01 2; do kubectl exec zk-$i -- hostname -f; done
zk-hs 서비스는 모든 파드를 위한 도메인인
zk-hs.default.svc.cluster.local을 만든다.
합의 프로토콜에서 각 참가자의 식별자는 유일해야 한다. Zab 프로토콜에서 동일한 고유 식별자를 요청하는 참가자는 없다. 이는 시스템 프로세스가 어떤 프로세스가 어떤 데이터를 커밋했는지 동의하게 하는데 필요하다. 2개 파드를 동일 순번으로 시작하였다면 두 대의 ZooKeeper 서버는 둘 다 스스로를 동일 서버로 식별한다.
합의 프로토콜에서 각 참여자의 식별자는 고유해야 한다. Zab 프로토콜에 두 참여자가 동일한 고유 식별자로 요청해서는 안된다. 이는 시스템 프로세스가 어떤 프로세스가 어떤 데이터를 커밋했는지 동의하도록 하기 위해 필수적이다. 동일 순번으로 두 개의 파드가 실행했다면 두 ZooKeeper 서버는 모두 동일한 서버로 식별된다.
서버가 Zab 프로토콜로 값을 커밋 시도하면, 합의를 이루어 값을 커밋하거나(리더 선출에 성공했고 나머지 두 개 파드도 Running과 Ready 상태라면) 실패한다(조건 중 하나라도 충족하지 않으면). 다른 서버를 대신하여 쓰기를 승인하는 상태는 발생하지 않는다.
앙상블 무결성 테스트
가장 기본적인 테스트는 한 ZooKeeper 서버에 데이터를 쓰고 다른 ZooKeeper 서버에서 데이터를 읽는 것이다.
아래 명령어는 앙상블 내에 zk-0 파드에서 /hello 경로로 world를 쓰는 스크립트인 zkCli.sh를 실행한다.
kubectl exec zk-0 zkCli.sh create /hello world
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
Created /hello
zk-1 파드에서 데이터를 읽기 위해 다음 명령어를 이용하자.
kubectl exec zk-1 zkCli.sh get /hello
zk-0에서 생성한 그 데이터는 앙상블 내에 모든 서버에서
사용할 수 있다.
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
world
cZxid = 0x100000002
ctime = Thu Dec 08 15:13:30 UTC 2016
mZxid = 0x100000002
mtime = Thu Dec 08 15:13:30 UTC 2016
pZxid = 0x100000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0
내구성있는 저장소 제공
ZooKeeper 기본 섹션에서 언급했듯이
ZooKeeper는 모든 항목을 내구성있는 WAL에 커밋하고 메모리 상태의 스냅샷을 저장 미디에에 주기적으로 저장한다.
내구성을 제공하기 위해 WAL을 이용하는 것은
복제된 상태 머신을 이루는 합의 프로토콜에서
이용하는 일반적인 기법이다.
zk 스테이트풀셋이 (재)스케줄링될 때 항상 동일한 퍼시스턴트볼륨을
ZooKeeper의 서버 디렉터리에 마운트한다.
파드를 재스케줄할 때에도 ZooKeeper의 WAL을 통해 이뤄진 모든 쓰기와
모든 그 스냅샷도 내구성을 유지한다.
일관된 구성 보장하기
리더 선출 촉진과
합의 달성 섹션에서 알렸듯이,
ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 일관된 설정이 필요하다.
또한 Zab 프로토콜의 일관된 설정도
네트워크에 걸쳐 올바르게 동작하기 위해서
필요하다. 이 예시에서는 매니페스트에 구성을 직접 포함시켜서 일관된 구성을
달성한다.
이는 컨테이너 내에서 안전하게 로깅하는 가장 단순한 방법이다.
표준 출력으로 애플리케이션 로그를 작성하면, 쿠버네티스는 로그 로테이션을 처리한다.
또한 쿠버네티스는 애플리케이션이 표준 출력과 표준 오류에 쓰인 로그로 인하여
로컬 저장 미디어가 고갈되지 않도록 보장하는 정상적인 보존 정책을 구현한다.
kubectl logs를 이용하거나 쿠버네티스 대시보드에서 표준 출력과 표준 오류로 쓰인 애플리케이션 로그를 볼 수 있다.
2016-12-06 19:34:16,236 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740
2016-12-06 19:34:16,237 [myid:1] - INFO [Thread-1136:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52740 (no session established for client)
2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52749
2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52749
2016-12-06 19:34:26,156 [myid:1] - INFO [Thread-1137:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52749 (no session established for client)
2016-12-06 19:34:26,222 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52750
2016-12-06 19:34:26,222 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52750
2016-12-06 19:34:26,226 [myid:1] - INFO [Thread-1138:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52750 (no session established for client)
2016-12-06 19:34:36,151 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52760
2016-12-06 19:34:36,152 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52760
2016-12-06 19:34:36,152 [myid:1] - INFO [Thread-1139:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52760 (no session established for client)
2016-12-06 19:34:36,230 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52761
2016-12-06 19:34:36,231 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52761
2016-12-06 19:34:36,231 [myid:1] - INFO [Thread-1140:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52761 (no session established for client)
2016-12-06 19:34:46,149 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52767
2016-12-06 19:34:46,149 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52767
2016-12-06 19:34:46,149 [myid:1] - INFO [Thread-1141:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52767 (no session established for client)
2016-12-06 19:34:46,230 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52768
2016-12-06 19:34:46,230 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52768
2016-12-06 19:34:46,230 [myid:1] - INFO [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client)
쿠버네티스는 많은 로그 솔루션과 통합된다. 클러스터와 애플리케이션에
가장 적합한 로그 솔루션을 선택할 수 있다. 클러스터 수준의
로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해 사이드카 컨테이너를 배포하는 것을 고려한다.
권한 없는 사용자를 위해 구성하기
컨테이너 내부의 권한있는 유저로 애플리케이션을 실행할 수 있도록 하는
최상의 방법은 논쟁거리이다.
조직에서 애플리케이션을 권한 없는 사용자가 실행한다면,
진입점을 실행할 사용자를 제어하기 위해
시큐리티컨텍스트를 이용할 수 있다.
zk스테이트풀셋의 파드 template은 SecurityContext를 포함한다.
securityContext:runAsUser:1000fsGroup:1000
파드 컨테이너에서 UID 1000은 ZooKeeper 사용자이며, GID 1000은
ZooKeeper의 그룹에 해당한다.
zk-0 파드에서 프로세스 정보를 얻어오자.
kubectl exec zk-0 -- ps -elf
securityContext 오브젝트의 runAsUser 필드 값이 1000 이므로
루트 사용자로 실행하는 대신 ZooKeeper 프로세스는 ZooKeeper 사용자로 실행된다.
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S zookeep+ 1 0 0 80 0 - 1127 - 20:46 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
0 S zookeep+ 27 1 0 80 0 - 1155556 - 20:46 ? 00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg
기본적으로 파드의 퍼시스턴트볼륨은 ZooKeeper 서버의 데이터 디렉터리에 마운트되고, 루트 사용자만이 접근 가능하다. 이 구성은 ZooKeeper 프로세스가 WAL에 기록하고 스냅샷을 저장하는 것을 방지한다.
zk-0 파드의 ZooKeeper 데이터 디렉터리의 권한을 얻어오는 아래 명령어를 이용하자.
kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data
securityContext 오브젝트의 fsGroup 필드 값이 1000 이므로, 파드의 퍼시스턴트 볼륨의 소유권은 ZooKeeper 그룹으로 지정되어 ZooKeeper 프로세스에서 읽고 쓸 수 있다.
drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data
ZooKeeper 프로세스 관리하기
ZooKeeper 문서에서는
"ZooKeeper의 서버 프로세스(JVM)을 관리할
감독 프로세스를 필요할 것이다."라고 말한다.
와치독(감독 프로세스)를 활용하여 실패한 프로세스를 재시작하는 것은 분산시스템에서
일반적인 방식이다. 쿠버네티스에서 애플리케이션을 배포할 때에는
감독 프로세스로 외부 유틸리티를 사용하기보다 쿠버네티스를 애플리케이션의
와치독으로서 사용해야 한다.
waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 1 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 2 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
statefulset rolling update complete 3 pods at revision zk-5db4499664...
이것은 파드를 역순으로 한 번에 하나씩 종료하고, 새로운 구성으로 재생성한다. 이는 롤링업데이트 동안에 쿼럼을 유지하도록 보장한다.
이력과 이전 구성을 보기 위해 kubectl rollout history 명령을 이용하자.
kubectl rollout history sts/zk
statefulsets "zk"
REVISION
1
2
수정사항을 롤백하기 위해 kubectl rollout undo 명령을 이용하자.
kubectl rollout undo sts/zk
statefulset.apps/zk rolled back
프로세스 장애 관리하기
재시작 정책은
쿠버네티스가 파드 내에 컨테이너의 진입점에서 프로세스 실패를 어떻게 다루는지 제어한다.
스테이트풀셋의 파드에서 오직 적절한 재시작 정책는 Always이며
이것이 기본 값이다. 상태가 유지되는 애플리케이션을 위해
기본 정책을 절대로 변경하지 말자.
zk-0 파드에서 실행 중인 ZooKeeper 서버에서 프로세스 트리를 살펴보기 위해 다음 명령어를 이용하자.
kubectl exec zk-0 -- ps -ef
컨테이너의 엔트리 포인트로 PID 1 인 명령이 사용되었으며
ZooKeeper 프로세스는 엔트리 포인트의 자식 프로세스로 PID 27 이다.
또 다른 터미널에서 다음 명령어로 zk-0 파드의 ZooKeeper 프로세스를 종료시킨다.
kubectl exec zk-0 -- pkill java
ZooKeeper 프로세스의 종료는 부모 프로세스의 종료를 일으킨다. 컨테이너 재시작정책이 Always이기 때문에 부모 프로세스를 재시작했다.
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 0 21m
zk-1 1/1 Running 0 20m
zk-2 1/1 Running 0 19m
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Error 0 29m
zk-0 0/1 Running 1 29m
zk-0 1/1 Running 1 29m
애플리케이션이 스크립트(zkServer.sh 같은)를 애플리케이션의 비지니스 로직을 구현한 프로세스를 시작하기 위해 이용한다면,
그 스크립트는 자식 프로세스와 함께 반드시 종료되어야 한다.
이는 쿠버네티스가 애플리케이션의 비지니스 로직을 구현한 프로세스가 실패할 때에
애플리케이션 컨테이너를 재시작하는 것을 보증한다.
활성도(Liveness) 테스트하기
실패한 애플리케이션을 재시작하도록 구성하는 것은 분산 시스템을
건강하게 유지하는데 충분하지 않다. 시스템의 프로세스는 살아있지만
응답이 없을 수 있고, 혹은 다른 건강하지 않은 경우의 시나리오가 있다.
애플리케이션 프로세스가 건강하지 않고 재시작해야만 한다는 것을
쿠버네티스에게 알리도록 활성도 검사를 이용해야 한다.
활성도와 준비도 검사가 동일함에도 둘 다 지정하는 것은 중요하다.
이는 ZooKeeper 앙상블에 건강한 서버만 아니라
네트워크 트래픽을 수신하는 것을 보장한다.
노드 실패 방지
ZooKeeper는 변조된 데이터를 성공적으로 커밋하기 위한 서버의 쿼럼이 필요하다.
3개의 서버 앙상블에서 성공적으로 저장하려면 2개 서버는 반드시 건강해야 한다.
쿼럼 기반 시스템에서, 멤버는 가용성을 보장하는
실패 영역에 걸쳐 배포된다.
중단을 방지하기 위해 개별 시스템의 손실로 인해 모범 사례에서는 동일한 시스템에
여러 인스턴스의 응용 프로그램을 함께 배치하는 것을 배제한다.
기본적으로 쿠버네티스는 동일 노드상에 스테이트풀셋의 파드를 위치시킬 수 있다.
생성한 3개의 서버 앙상블에서 2개의 서버가 같은 노드에 있다면, 그 노드는 실패하고
ZooKeeper 서비스 클라이언트는 그 파드들의 최소 하나가 재스케줄링될 때까지 작동 중단을 경험할 것이다.
노드 실패하는 사건 중에도 중요 시스템의 프로세스가 재스케줄될 수 있게
항상 추가적인 용량을 프로비전해야 한다. 그렇게 하면 쿠버네티스 스케줄러가
ZooKeeper 서버 하나를 다시 스케줄하는 동안까지만 작동 중단될 것이다.
그러나 서비스에서 노드 실패로 인한 다운타임을 방지하려 한다면,
파드안티어피니티를 설정해야 한다.
zk스테이트풀셋의 파드의 노드를 알아보기 위해 다음 명령어를 이용하자.
for i in 01 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo""; done
requiredDuringSchedulingIgnoredDuringExecution 필드는
쿠버네티스 스케줄러에 topologyKey로 정의된 도메인에서 app이 zk라고 레이블링된
두 개 파드가 위치하지 않도록 한다.
topologyKeykubernetes.io/hostname은 도메인이 개별 노드임을 나타낸다.
다른 규칙과 레이블, 셀렉터를 사용하여
앙상블을 물리적인, 네트워크, 전원 장애 분야에 걸쳐 확산하도록 이 기법을 확장할 수 있다.
생존 유지
이 섹션에서는 노드를 통제(cordon)하고 비운다(drain). 공유된 클러스터에서 이 튜토리얼을 진행한다면,
다른 테넌트에 부정적인 영향을 비치지 않음을 보증해야 한다.
이전 섹션은 계획되지 않은 노드 실패에서 살아남도록
어떻게 파드를 확산할 것인가에 대해 알아보았다.
그러나 계획된 점검으로 인해 발생하는 일시적인 노드 실패에 대한 계획도 필요하다.
클러스터에서 다음 명령으로 노드를 살펴보자.
kubectl get nodes
kubectl cordon을 이용하여
클러스터 내에 4개 노드를 제외하고 다른 모든 노드를 통제해보자.
kubectl cordon <노드-이름>
zk-pdbPodDisruptionBudget을 살펴보고자 이 명령어를 이용하자.
kubectl get pdb zk-pdb
max-unavailable 필드는 쿠버네티스가 zk스테이트풀셋에서 최대 1개의 파드는
언제든지 가용하지 않을 수 있음을 나타낸다.
NAME MIN-AVAILABLE MAX-UNAVAILABLE ALLOWED-DISRUPTIONS AGE
zk-pdb N/A 1 1
한 터미널에서 zk스테이트풀셋의 파드를 지켜보는 이 명령어를 이용하자.
kubectl get pods -w -l app=zk
다른 터미널에서 현재 스케줄되는 파드의 노드를 살펴보자.
for i in 01 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo""; done
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
node "kubernetes-node-i4c4" cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
WARNING: Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog; Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4
There are pending pods when an error occurred: Cannot evict pod as it would violate the pod's disruption budget.
pod/zk-2
kubectl 을 종료하기 위해 CTRL-C를 이용하자.
zk-2를 추출하는 것은 zk-budget을 위반하기 때문에 셋째 노드를 비울 수 없다. 그러나 그 노드는 통제 상태로 남는다.
zk-0에서 온전성 테스트 때에 입력한 값을 가져오는 zkCli.sh를 이용하자.
kubectl exec zk-0 zkCli.sh get /hello
PodDisruptionBudget이 존중되기 때문에 서비스는 여전히 가용하다.
WatchedEvent state:SyncConnected type:None path:null
world
cZxid = 0x200000002
ctime = Wed Dec 07 00:08:59 UTC 2016
mZxid = 0x200000002
mtime = Wed Dec 07 00:08:59 UTC 2016
pZxid = 0x200000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
출력은
node "kubernetes-node-i4c4" already cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
pod "heapster-v1.2.0-2604621511-wht1r" deleted
pod "zk-2" deleted
node "kubernetes-node-i4c4" drained
이번엔 kubectl drain 이 성공한다.
zk-2가 재스케줄되도록 두 번째 노드의 통제를 풀어보자.
kubectl uncordon kubernetes-node-ixsl
node "kubernetes-node-ixsl" uncordoned
kubectl drain을 PodDisruptionBudget과 결합하면 유지보수 중에도 서비스를 가용하게 할 수 있다.
drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면
서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다.
파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다.
정리하기
kubectl uncordon은 클러스터 내에 모든 노드를 통제 해제한다.
반드시 이 튜토리얼에서 사용한 퍼시스턴트 볼륨을 위한 퍼시스턴트 스토리지 미디어를 삭제하자.
귀하의 환경과 스토리지 구성과 프로비저닝 방법에서 필요한 절차를 따라서
모든 스토리지가 재확보되도록 하자.
5.6 - 클러스터
5.6.1 - AppArmor를 사용하여 리소스에 대한 컨테이너의 접근 제한
FEATURE STATE:Kubernetes v1.4 [beta]
AppArmor는 표준 리눅스 사용자와 그룹 기반의 권한을 보완하여, 한정된 리소스 집합으로
프로그램을 제한하는 리눅스 커널 보안 모듈이다. AppArmor는 임의의 애플리케이션에 대해서
잠재적인 공격 범위를 줄이고 더욱 심층적인 방어를 제공하도록 구성할 수 있다.
이 기능은 특정 프로그램이나 컨테이너에서 필요한 리눅스 기능, 네트워크 사용, 파일 권한 등에 대한
접근을 허용하는 프로파일로 구성한다. 각 프로파일은
허용하지 않은 리소스 접근을 차단하는 강제(enforcing) 모드 또는
위반만을 보고하는 불평(complain) 모드로 실행할 수 있다.
AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한하고 또는
시스템 로그를 통해 더 나은 감사를 제공하여 더 안전한 배포를 실행할 수 있다.
그러나 AppArmor가 은탄환(언제나 통하는 무적의 방법)이 아니며,
애플리케이션 코드 취약점을 보호하기 위한 여러 조치를 할 수 있는 것 뿐임을 잊으면 안된다.
양호하고 제한적인 프로파일을 제공하고, 애플리케이션과 클러스터를 여러 측면에서 강화하는 것이 중요하다.
목적
노드에 프로파일을 어떻게 적재하는지 예시를 본다.
파드에 프로파일을 어떻게 강제 적용하는지 배운다.
프로파일이 적재되었는지 확인하는 방법을 배운다.
프로파일을 위반하는 경우를 살펴본다.
프로파일을 적재할 수 없을 경우를 살펴본다.
시작하기 전에
다음을 보장해야 한다.
쿠버네티스 버전은 최소 1.4 이다. -- 쿠버네티스 v1.4부터 AppArmor 지원을 추가했다.
v1.4 이전 쿠버네티스 컴포넌트는 새로운 AppArmor 어노테이션을 인식하지 못하고
제공되는 AppArmor 설정을 조용히 무시할 것이다. 파드에서 예상하는 보호를 받고 있는지 확인하려면
해당 노드의 Kubelet 버전을 확인하는 것이 중요하다.
$ kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}\n{end}'
AppArmor 커널 모듈을 사용 가능해야 한다. -- 리눅스 커널에 AppArmor 프로파일을 강제 적용하기 위해 AppArmor 커널 모듈은 반드시 설치되어 있고
사용 가능해야 한다. 예를 들어 Ubuntu 및 SUSE 같은 배포판은 모듈을 기본값으로 지원하고, 그 외 많은 다른 배포판들은 선택적으로 지원한다.
모듈이 사용 가능한지 확인하려면
/sys/module/apparmor/parameters/enabled 파일을 확인한다.
$ cat /sys/module/apparmor/parameters/enabled
Y
Kubelet(>=v1.4)이 AppArmor 기능 지원을 포함하지만, 커널 모듈을 사용할 수 없으면
파드에서 AppArmor 옵션을 실행하는 것이 거부된다.
참고: 우분투에는 추가적인 훅(hook)이나 추가 기능 패치를 포함한 리눅스 커널의 상위 스트림에 머지되지 않은
많은 AppArmor 패치를 가지고 있다. 쿠버네티스는
상위 스트림 버전에서 테스트한 패치만을 가지고 있어서 다른 기능은 지원을 보장하지 않는다.
컨테이너 런타임이 AppArmor을 지원한다. -- 현재 모든 일반적인 쿠버네티스를 지원하는
도커(Docker), CRI-O 또는
containerd 와 같은 컨테이너 런타임들은 AppArmor를 지원해야 한다.
이 런타임 설명서를 참조해서 클러스터가 AppArmor를 사용하기 위한
요구 사항을 충족하는지 확인해야 한다.
프로파일이 적재되어 있다. -- AppArmor는 각 컨테이너와 함께 실행해야 하는 AppArmor 프로파일을 지정하여 파드에 적용한다.
커널에 지정한 프로파일이 적재되지 않았다면, Kubelet(>= v1.4)은 파드를 거부한다. 해당 노드에 어떤 프로파일이 적재되었는지는
/sys/kernel/security/apparmor/profiles 파일을 통해 확인할 수 있다.
예를 들어,
AppArmor 지원이 포함된 Kubelet (>= v1.4)이면
어떤 전제 조건이 충족되지 않으면 AppArmor와 함께한 파드를 거부한다.
노드 상에 AppArmor 지원 여부는
노드 준비 조건 메시지를 확인하여(이후 릴리스에서는 삭제될 것 같지만) 검증할 수 있다.
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled
gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled
gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled
파드 보안 강화하기
참고: AppArmor는 현재 베타라서 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면,
어노테이션은 최상위 종류의 필드로 대체될 것이다(자세한 내용은
일반 사용자 버전으로 업그레이드 방법 참고)
AppArmor 프로파일은 컨테이너마다 지정된다. 함께 실행할 파드 컨테이너에 AppArmor 프로파일을 지정하려면
파드의 메타데이터에 어노테이션을 추가한다.
쿠버네티스 AppArmor 의 작동 순서는 모든 선행 조건이 충족되었는지 확인하고,
적용을 위해 선택한 프로파일을 컨테이너 런타임으로 전달하여 이루어진다.
만약 선행 조건이 충족되지 않으면 파드는 거부되고 실행되지 않는다.
프로파일이 적용되었는지 확인하기 위해, 컨테이너 생성 이벤트에 나열된 AppArmor 보안 옵션을 찾아 볼 수 있다.
kubectl get events | grep Created
22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-node-pool-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]apparmor=k8s-apparmor-example-deny-write]
컨테이너의 루트 프로세스가 올바른 프로파일로 실행되는지는 proc attr을 확인하여 직접 검증할 수 있다.
kubectl exec <pod_name> cat /proc/1/attr/current
k8s-apparmor-example-deny-write (enforce)
예시
이 예시는 AppArmor를 지원하는 클러스터를 이미 구성하였다고 가정한다.
먼저 노드에서 사용하려는 프로파일을 적재해야 한다. 사용할 프로파일은 파일 쓰기를 거부한다.
apiVersion:v1kind:Podmetadata:name:hello-apparmorannotations:# 쿠버네티스에 'k8s-apparmor-example-deny-write' AppArmor 프로파일을 적용함을 알린다.# 잊지 말 것은 쿠버네티스 노드에서 실행 중인 버전이 1.4 이상이 아닌 경우에는 이 설정은 무시된다는 것이다.container.apparmor.security.beta.kubernetes.io/hello:localhost/k8s-apparmor-example-deny-writespec:containers:- name:helloimage:busyboxcommand:["sh","-c","echo 'Hello AppArmor!' && sleep 1h"]
kubectl create -f ./hello-apparmor.yaml
파드 이벤트를 살펴보면, 'k8s-apparmor-example-deny-write' AppArmor 프로파일로 생성된 파드 컨테이너를
확인할 수 있다.
kubectl get events | grep hello-apparmor
14s 14s 1 hello-apparmor Pod Normal Scheduled {default-scheduler } Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2
14s 14s 1 hello-apparmor Pod spec.containers{hello} Normal Pulling {kubelet gke-test-default-pool-239f5d02-gyn2} pulling image "busybox"
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Pulled {kubelet gke-test-default-pool-239f5d02-gyn2} Successfully pulled image "busybox"
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet gke-test-default-pool-239f5d02-gyn2} Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Started {kubelet gke-test-default-pool-239f5d02-gyn2} Started container with docker id 06b6cd1c0989
proc attr을 확인하여 컨테이너가 실제로 해당 프로파일로 실행 중인지 확인할 수 있다.
스케줄러는 어떤 프로파일이 어떤 노드에 적재되는지 고려하지 않으니, 프로파일 전체 집합이
모든 노드에 적재되어야 한다. 대안적인 방법은
각 프로파일(혹은 프로파일의 클래스)을 위한 노드 레이블을 노드에 추가하고,
노드 셀렉터를 이용하여
파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.
PodSecurityPolicy로 프로파일 제한하기
만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 apiserver에 설정해야 한다.
기본 프로파일 이름 옵션은 프로파일을 지정하지 않았을 때에
컨테이너에 기본으로 적용하는 프로파일을 지정한다.
허용하는 프로파일 이름 옵션은 파드 컨테이너가 함께 실행하도록 허용되는 프로파일 목록을 지정한다.
두 옵션을 모두 사용하는 경우, 기본값은 반드시 필요하다.
프로파일은 컨테이너에서 같은 형식으로 지정된다. 전체 사양은 API 참조를 찾아본다.
AppArmor 비활성화
클러스터에서 AppArmor 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다.
--feature-gates=AppArmor=false
비활성화되면 AppArmor 프로파일을 포함한 파드는 "Forbidden" 오류로 검증 실패한다.
기본적으로 도커는 항상 비특권 파드에 "docker-default" 프로파일을 활성화하고(AppArmor 커널모듈이 활성화되었다면),
기능 게이트가 비활성화된 것처럼 진행한다.
AppArmor를 비활성화하는 이 옵션은
AppArmor가 일반 사용자 버전이 되면 제거된다.
AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기
클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다.
그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 PodSecurityPolicy 승인)을 거치지 않는다.
그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여
파드의 권한을 docker-default 보다 높일 수 있다.
이것이 염려된다면 apparmor.security.beta.kubernetes.io 어노테이션이 포함된
모든 파드의 클러스터를 제거하는 것이 좋다.
일반 사용자 버전으로 업그레이드 방법
AppArmor는 일반 사용자 버전(general available)으로 준비되면 현재 어노테이션으로 지정되는 옵션은 필드로 변경될 것이다.
모든 업그레이드와 다운그레이드 방법은 전환을 통해 지원하기에는 매우 미묘하니
전환이 필요할 때에 상세히 설명할 것이다.
최소 두 번의 릴리스에 대해서는 필드와 어노테이션 모두를 지원할 것이고,
그 이후부터는 어노테이션은 명확히 거부된다.
프로파일 제작
AppArmor 프로파일을 만들고 올바르게 지정하는 것은 매우 까다로울 수 있다.
다행히 이 작업에 도움 되는 도구가 있다.
aa-genprof와 aa-logprof는 애플리케이션 활동과 로그와 수행에 필요한 행동을 모니터링하여
일반 프로파일 규칙을 생성한다. 자세한 사용방법은
AppArmor 문서에서 제공한다.
bane은 단순화된 프로파일 언어를 이용하는 도커를 위한
AppArmor 프로파일 생성기이다.
개발 장비의 도커를 통해 애플리케이션을 실행하여
프로파일을 생성하는 것을 권장하지만,
파드가 실행 중인 쿠버네티스 노드에서 도구 실행을 금하지는 않는다.
AppArmor 문제를 디버깅하기 위해서 거부된 것으로 보이는 시스템 로그를 확인할 수 있다.
AppArmor 로그는 dmesg에서 보이며, 오류는 보통 시스템 로그나
journalctl에서 볼 수 있다. 더 많은 정보는
AppArmor 실패에서 제공한다.
API 참조
파드 어노테이션
컨테이너를 실행할 프로파일을 지정한다.
키: container.apparmor.security.beta.kubernetes.io/<container_name><container_name>는 파드 내에 컨테이너 이름과 일치한다.
분리된 프로파일은 파드 내에 각 컨테이너로 지정할 수 있다.
값: 아래 기술된 프로파일 참조
프로파일 참조
runtime/default: 기본 런타임 프로파일을 참조한다.
(기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고
AppArmor를 사용하는 것과 동등하다.
도커에서는 권한 없는 컨테이너의 경우는
docker-default 프로파일로,
권한이 있는 컨테이너의 경우 unconfined(프로파일 없음)으로 해석한다.
localhost/<profile_name>: 노드(localhost)에 적재된 프로파일을 이름으로 참조한다.
iptables 모드
(기본값)에서 kube-proxy를 운영하는 경우 클러스터 내에서
클러스터IP로 패킷을 보내면
소스 NAT를 통과하지 않는다. kube-proxy가 실행중인 노드에서
http://localhost:10249/proxyMode 를 입력해서 kube-proxy 모드를 조회할 수 있다.
kubectl get nodes
출력은 다음과 유사하다
NAME STATUS ROLES AGE VERSION
kubernetes-node-6jst Ready <none> 2h v1.13.0
kubernetes-node-cx31 Ready <none> 2h v1.13.0
kubernetes-node-jj1t Ready <none> 2h v1.13.0
한 노드의 프록시 모드를 확인한다. (kube-proxy는 포트 10249에서 수신대기한다.)
# 질의 할 노드의 쉘에서 이것을 실행한다.
curl localhost:10249/proxyMode
출력은 다음과 같다.
iptables
소스 IP 애플리케이션을 통해 서비스를 생성하여 소스 IP 주소 보존 여부를 테스트할 수 있다.
이를 피하기 위해 쿠버네티스는
클라이언트 소스 IP 주소를 보존하는 기능이 있다.
service.spec.externalTrafficPolicy 의 값을 Local 로 하면
오직 로컬 엔드포인트로만 프록시 요청하고
다른 노드로 트래픽 전달하지 않는다. 이 방법은 원본
소스 IP 주소를 보존한다. 만약 로컬 엔드 포인트가 없다면,
그 노드로 보내진 패킷은 버려지므로
패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로,
패킷을 엔드포인트까지 전달할 수 있다.
다음과 같이 service.spec.externalTrafficPolicy 필드를 설정하자.
Type=LoadBalancer인
서비스로 보낸 패킷은 소스 NAT를 기본으로 하는데, Ready 상태로
모든 스케줄된 모든 쿠버네티스 노드는
로드 밸런싱 트래픽에 적합하다. 따라서 엔드포인트가 없는 노드에
패킷이 도착하면 시스템은 엔드포인트를 포함한 노드에 프록시를
수행하고 패킷 상에서 노드의 IP 주소로 소스 IP 주소를 변경한다
(이전 섹션에서 기술한 것처럼).
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m
다음으로 이 서비스의 외부 IP에 요청을 전송한다.
curl 203.0.113.140
다음과 유사하게 출력된다.
CLIENT VALUES:
client_address=10.240.0.5
...
그러나 구글 클라우드 엔진/GCE 에서 실행 중이라면 동일한 service.spec.externalTrafficPolicy 필드를 Local로 설정하면
서비스 엔드포인트가 없는 노드는 고의로 헬스 체크에 실패하여
강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서
자신을 스스로 제거한다.
쿠버네티스에 의해 service.spec.healthCheckNodePort 필드가
즉각적으로 할당되는 것을 봐야 한다.
kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
출력은 다음과 유사하다.
healthCheckNodePort:32122
service.spec.healthCheckNodePort 필드는 /healthz에서 헬스 체크를 제공하는
모든 노드의 포트를 가르킨다. 이것을 테스트할 수 있다.
kubectl get pod -o wide -l run=source-ip-app
출력은 다음과 유사하다.
NAME READY STATUS RESTARTS AGE IP NODE
source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst
다양한 노드에서 /healthz 엔드포인트를 가져오려면 curl 을 사용한다.
# 선택한 노드에서 로컬로 이것을 실행한다.
curl localhost:32122/healthz
1 Service Endpoints found
다른 노드에서는 다른 결과를 얻을 수 있다.
# 선택한 노드에서 로컬로 이것을 실행한다.
curl localhost:32122/healthz
No Service Endpoints Found
컨트롤 플레인에서
실행중인 컨트롤러는 클라우드 로드 밸런서를 할당한다. 또한 같은 컨트롤러는
각 노드에서 포트/경로(port/path)를 가르키는 HTTP 상태 확인도 할당한다.
엔드포인트가 없는 2개의 노드가 상태 확인에 실패할
때까지 약 10초간 대기한 다음,
curl 을 사용해서 로드밸런서의 IPv4 주소를 쿼리한다.
curl 203.0.113.140
출력은 다음과 유사하다.
CLIENT VALUES:
client_address=198.51.100.79
...
크로스-플랫폼 지원
일부 클라우드 공급자만 Type=LoadBalancer 를 사용하는
서비스를 통해 소스 IP 보존을 지원한다.
실행 중인 클라우드 공급자에서 몇 가지 다른 방법으로
로드밸런서를 요청한다.
클라이언트 연결을 종료하고 새 연결을 여는 프록시를 이용한다.
이 경우 소스 IP 주소는 클라이언트 IP 주소가 아니고
항상 클라우드 로드밸런서의 IP 주소이다.
로드밸런서의 VIP에 전달된 클라이언트가 보낸 요청을
중간 프록시가 아닌 클라이언트 소스 IP 주소가 있는 노드로
끝나는 패킷 전달자를 이용한다.
첫 번째 범주의 로드밸런서는 진짜 클라이언트 IP를 통신하기 위해
HTTP Forwarded
또는 X-FORWARDED-FOR
헤더 또는
프록시 프로토콜과
같은 로드밸런서와 백엔드 간에 합의된 프로토콜을 사용해야 한다.
두 번째 범주의 로드밸런서는 서비스의 service.spec.healthCheckNodePort 필드의 저장된 포트를 가르키는
HTTP 헬스 체크를 생성하여
위에서 설명한 기능을 활용할 수 있다.
JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서
동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
API와 릴리스 버전 부여에 관한 제안에는
API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
API 변경 문서에서
각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.
아래는 각 수준의 기준에 대한 요약이다.
알파(Alpha):
버전 이름에 alpha가 포함된다(예: v1alpha1).
버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다.
기본적으로 비활성화되어 있다.
기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
버그에 대한 위험이 높고 장기간 지원되지 않으므로
단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
베타(Beta):
버전 이름에 beta가 포함된다(예: v2beta3).
코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다.
기본적으로 활성화되어 있다.
구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서
호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로
이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이
필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다.
이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서
호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서
독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.
참고: 베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는
실질적으로 더 많은 변경이 어렵다.
안정화(Stable):
버전 이름이 vX이고 X 는 정수다.
안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.
API 그룹
API 그룹은
쿠버네티스 API를 더 쉽게 확장하게 해준다.
API 그룹은 REST 경로와 직렬화된 오브젝트의 apiVersion 필드에
명시된다.
쿠버네티스에는 다음과 같은 다양한 API 그룹이 있다.
핵심 (또는 레거시 라고 불리는) 그룹은 REST 경로 /api/v1에 있다.
핵심 그룹은 apiVersion 필드의 일부로 명시되지 않는다. 예를
들어, apiVersion: v1 과 같다.
이름이 있는 그룹은 REST 경로 /apis/$GROUP_NAME/$VERSION에 있으며
apiVersion: $GROUP_NAME/$VERSION을 사용한다(예를 들어, apiVersion: batch/v1).
지원되는 API 그룹 전체의 목록은
쿠버네티스 API 참조 문서에서 확인할 수 있다.
API 그룹 활성화 또는 비활성화
특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서
--runtime-config 를 설정하여 활성화 또는 비활성화할 수 있다.
--runtime-config 플래그는 API 서버의 런타임 구성을 설명하는
쉼표로 구분된 <key>=<value> 쌍을 허용한다. 만약 =<value>
부분을 생략하면, =true 가 명시된 것처럼 취급한다. 예를 들면, 다음과 같다.
batch/v1 을 비활성화하려면, --runtime-config=batch/v1=false 로 설정
batch/v2alpha1 을 활성화하려면, --runtime-config=batch/v2alpha1 으로 설정
참고: 그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여
--runtime-config 변경을 반영해야 한다.
이 페이지는 다양한 프로그래밍 언어에서 쿠버네티스 API를 사용하기 위한
클라이언트 라이브러리에 대한 개요를 포함하고 있다.
쿠버네티스 REST API를 사용해 애플리케이션을 작성하기 위해
API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다.
클라이언트 라이브러리는 대체로 인증과 같은 공통의 태스크를 처리한다.
대부분의 클라이언트 라이브러리들은 API 클라이언트가 쿠버네티스 클러스터 내부에서 동작하는 경우 인증
또는 kubeconfig 파일 포맷을 통해
자격증명과 API 서버 주소를 읽을 수 있게
쿠버네티스 서비스 어카운트를 발견하고 사용할 수 있다.
주의:
이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.
다음의 쿠버네티스 API 클라이언트 라이브러리들은 쿠버네티스 팀이 아닌
각각의 저자들이 제공하고 관리한다.
쿠버네티스 API 서버는 현재 상태를 나타내는 API 엔드포인트를 제공한다.
이 페이지에서는 API 엔드포인트들에 대해 설명하고 이를 사용하는 방법을 다룬다.
헬스를 위한 API 엔드포인트
쿠버네티스 API 서버는 현재 상태를 나타내는 세 가지 API 엔드포인트(healthz, livez 와 readyz)를 제공한다.
healthz 엔드포인트는 사용 중단(deprecated)됐으며 (쿠버네티스 v1.16 버전 이후), 대신 보다 구체적인 livez 와 readyz 엔드포인트를 사용해야 한다.
livez 엔드포인트는 --livez-grace-period플래그 옵션을 사용하여 시작 대기 시간을 지정할 수 있다.
/readyz 엔드포인트는 --shutdown-delay-duration플래그 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다.
API 서버의 health/livez/readyz 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다.
상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 healthy/live/ready 상태를 나타낸다.
아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다.
다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다.
모든 엔드포인트는 verbose 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다.
이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다.
curl -k https://localhost:6443/livez?verbose
인증을 사용하는 원격 호스트에서 사용할 경우에는 다음과 같이 수행한다.
kubectl get --raw='/readyz?verbose'
출력은 다음과 같다.
[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
healthz check passed
또한 쿠버네티스 API 서버는 특정 체크를 제외할 수 있다.
쿼리 파라미터는 다음 예와 같이 조합될 수 있다.
[+]ping ok
[+]log ok
[+]etcd excluded: ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]shutdown ok
healthz check passed
개별 헬스 체크
FEATURE STATE:Kubernetes v1.20 [alpha]
각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
개별 체크를 위한 스키마는 /livez/<healthcheck-name> 이고, 여기서 livez 와 readyz 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
<healthcheck-name> 경로 위에서 설명한 verbose 플래그를 사용해서 찾을 수 있고, [+] 와 ok 사이의 경로를 사용한다.
이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.
인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다.
가끔은 서비스 어카운트를 더 잘 설명하기 위해 준비 중인 기능을 참조한다.
사용자 어카운트와 서비스 어카운트 비교
쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
구분한다.
사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
위한 것이다.
사용자 어카운트는 전역을 대상으로 고려된다.
클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 서비스 어카운트는 네임스페이스에 할당된다.
일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
서비스 어카운트 생성은
클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록
보다 가볍게 만들어졌다.
사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에
이러한 설정은 이식성이 좋다.
서비스 어카운트 자동화
서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.
ServiceAccount 어드미션 컨트롤러
토큰 컨트롤러
ServiceAccount 컨트롤러
서비스어카운트(ServiceAccount) 어드미션 컨트롤러
파드 수정은 어드미션 컨트롤러라는
플러그인을 통해 구현된다.
이것은 API 서버의 일부이다.
파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.
파드에 ServiceAccount 가 없다면, ServiceAccount 를 default 로 설정한다.
파드에 참조되는 ServiceAccount 가 있도록 하고, 그렇지 않으면 이를 거부한다.
파드에 ImagePullSecrets 이 없는 경우, ServiceAccount 의 ImagePullSecrets 이 파드에 추가된다.
파드에 API 접근을 위한 토큰이 포함된 volume 을 추가한다.
/var/run/secrets/kubernetes.io/serviceaccount 에 마운트된 파드의 각 컨테이너에 volumeSource 를 추가한다.
바인딩된 서비스 어카운트 토큰 볼륨
FEATURE STATE:Kubernetes v1.13 [alpha]
BoundServiceAccountTokenVolume 기능 게이트가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가
시크릿 볼륨 대신 프로젝티드 서비스 어카운트 토큰 볼륨을 추가한다. 서비스 어카운트 토큰은 기본적으로 1시간 후에 만료되거나 파드가 삭제된다. 프로젝티드 볼륨에 대한 자세한 내용을 참고한다.
이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 활성화된 RootCAConfigMap 기능 게이트에 따라 다르다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다.
파드에 참조되는 serviceAccountName가 있도록 하고, 그렇지 않으면
이를 거부한다.
파드에 imagePullSecrets이 없는 경우, 서비스어카운트의
imagePullSecrets이 파드에 추가된다.
서비스어카운트 automountServiceAccountToken 또는 파드의
automountServiceAccountToken 이 false 로 설정되지 않은 경우
파드에 API 접근 토큰이 포함된 volume을 추가한다.
이전 단계에서 서비스어카운트 토큰에 대한 볼륨을 생성한 경우,
/var/run/secrets/kubernetes.io/serviceaccount에 마운트된
파드의 각 컨테이너에 volumeSource를 추가한다.
BoundServiceAccountTokenVolume 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다.
프로젝티드 볼륨에 대한
자세한 내용을 참조한다.
토큰 컨트롤러
토큰컨트롤러는 kube-controller-manager 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
서비스어카운트 생성을 감시하고 API에 접근할 수 있는 해당
서비스어카운트 토큰 시크릿을 생성한다.
서비스어카운트 삭제를 감시하고 해당하는 모든 서비스어카운트
토큰 시크릿을 삭제한다.
서비스어카운트 토큰 시크릿 추가를 감시하고, 참조된 서비스어카운트가
존재하는지 확인하고, 필요한 경우 시크릿에 토큰을 추가한다.
시크릿 삭제를 감시하고 필요한 경우 해당 서비스어카운트에서
참조를 제거한다.
서비스 어카운트 개인키 파일은 --service-account-private-key-file
플래그를 사용하여 kube-controller-manager 의 토큰 컨트롤러에 전달해야
한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
마찬가지로 --service-account-key-file 플래그를 사용하여 해당 공개키를
kube-apiserver 에 전달해야 한다. 공개키는 인증 과정에서 토큰을
검증하는 데 사용될 것이다.
추가적인 API 토큰 생성
컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다.
서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해
서비스어카운트를 참조하는 어노테이션과 함께 kubernetes.io/service-account-token 유형의 시크릿을 생성하면
컨트롤러가 새로 생성된 토큰으로 갱신한다.
서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고
"default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
6.3.2 - 인가 개요
지원되는 인가 모듈을 사용하여 정책을 만드는 방법을 포함한
쿠버네티스 인가에 대해 자세히 알아보자.
쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다.
인증에 대한 자세한 내용은 쿠버네티스 API 접근 제어하기를
참고한다.
쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다.
이는 쿠버네티스 인가가 쿠버네티스 API 이외에 다른 API를 처리할 수 있는
기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과
연동된다는 것을 의미한다.
요청 허용 또는 거부 결정
쿠버네티스는 API 서버를 이용하여 API 요청을 인가한다.
모든 정책과 비교하여 모든 요청 속성을 평가하고 요청을 허용하거나 거부한다.
계속 진행하려면 API 요청의 모든 부분이 일부 정책에 의해 반드시 허용되어야 한다.
이는 기본적으로 승인이 거부된다는 것을 의미한다.
(쿠버네티스는 API 서버를 사용하지만,
특정 오브젝트의 특정 필드에 의존하는 접근 제어 및 정책은
어드미션 컨트롤러에 의해 처리된다.)
여러 개의 인가 모듈이 구성되면 각 모듈이 순서대로 확인된다.
어느 인가 모듈이 요청을 승인하거나 거부할 경우, 그 결정은 즉시 반환되며 다른 인가 모듈이 참고되지 않는다.
모든 모듈에서 요청에 대한 평가가 없으면 요청이 거부된다.
요청 거부는 HTTP 상태 코드 403을 반환한다.
요청 속성 검토
쿠버네티스는 다음 API 요청 속성만 검토한다.
user - 인증 중에 제공된 user 문자열.
group - 인증된 사용자가 속한 그룹 이름 목록.
extra - 인증 계층에서 제공하는 문자열 값에 대한 임의의 문자열 키 맵.
API - 요청이 API 리소스에 대한 것인지 여부.
Request path - /api 또는 /healthz와 같이 다양한 리소스가 아닌 엔드포인트의 경로.
API request verb - get, list, create, update, patch, watch, delete, deletecollection과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 요청 동사 결정을 참고한다.
HTTP request verb - get, post, put, delete처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다.
Resource - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- get, update, patch, delete 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
Subresource - 접근 중인 하위 리소스(리소스 요청만 해당).
Namespace - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당)
API group - 접근 중인 API 그룹(리소스 요청에만 해당). 빈 문자열은 핵심(core)API 그룹을 지정한다.
요청 동사 결정
리소스가 아닌 요청/api/v1/... 또는 /apis/<group>/<version>/... 이외에 다른 엔드포인트에 대한 요청은
"리소스가 아닌 요청"으로 간주되며, 요청의 소문자 HTTP 메서드를 동사로 사용한다.
예를 들어, /api 또는 /healthz와 같은 엔드포인트에 대한 GET 요청은 get을 동사로 사용할 것이다.
리소스 요청
리소스 API 엔드포인트에 대한 요청 동사를 결정하려면
사용된 HTTP 동사와 해당 요청이 개별 리소스 또는 리소스 모음에 적용되는지 여부를
검토한다.
HTTP 동사
요청 동사
POST
create
GET, HEAD
get(개별 리소스), list(전체 오브젝트 내용을 포함한 리소스 모음), watch(개별 리소스 또는 리소스 모음을 주시)
핵심 API 그룹의 users, groups, serviceaccounts와 authentication.k8s.io API 그룹의 userextras 동사.
인가 모드
쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다.
Node - 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 Node 인가을 참조한다.
ABAC - 속성 기반 접근 제어 (ABAC, Attribute-based access control)는 속성과 결합한 정책의 사용을 통해 사용자에게 접근 권한을 부여하는 접근 제어 패러다임을 말한다. 이 정책은 모든 유형의 속성(사용자 속성, 리소스 속성, 오브젝트, 환경 속성 등)을 사용할 수 있다. ABAC 모드 사용에 대한 자세한 내용은 ABAC 모드를 참조한다.
RBAC - 역할 기반 접근 제어(RBAC, Role-based access control)는 기업 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다. RBAC 모드 사용에 대한 자세한 내용은 RBAC 모드를 참조한다.
지정된 RBAC(역할 기반 접근 제어)이 인가 결정을 위해 rbac.authorization.k8s.io API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다.
RBAC을 활성화하려면 --authorization-mode=RBAC로 API 서버를 시작한다.
Webhook - WebHook은 HTTP 콜백이다(어떤 일이 일어날 때 발생하는 HTTP POST와 HTTP POST를 통한 간단한 이벤트 알림). WebHook을 구현하는 웹 애플리케이션은 특정한 일이 발생할 때 URL에 메시지를 POST 할 것이다. Webhook 모드 사용에 대한 자세한 내용은 Webhook 모드를 참조한다.
API 접근 확인
kubectl은 API 인증 계층을 신속하게 쿼리하기 위한 "auth can-i" 하위 명령어를 제공한다.
이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 SelfSubjectAccessReview API를 사용하며,
사용되는 인가 모드에 관계없이 작동한다.
kubectl auth can-i create deployments --namespace dev
kubectl auth can-i list secrets --namespace dev --as dave
다음과 유사하게 출력된다.
no
SelfSubjectAccessReview는 authorization.k8s.io API 그룹의 일부로서
API 서버 인가를 외부 서비스에 노출시킨다.
이 그룹의 기타 리소스에는 다음이 포함된다.
SubjectAccessReview - 현재 사용자뿐만 아니라 모든 사용자에 대한 접근 검토. API 서버에 인가 결정을 위임하는 데 유용하다. 예를 들어, kubelet 및 확장(extension) API 서버는 자신의 API에 대한 사용자 접근을 결정하기 위해 해당 리소스를 사용한다.
LocalSubjectAccessReview - SubjectAccessReview와 비슷하지만 특정 네임스페이스로 제한된다.
SelfSubjectRulesReview - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다.
이러한 API는 반환된 오브젝트의 응답 "status" 필드가 쿼리의 결과인
일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다.
--authorization-mode=ABAC 속성 기반 접근 제어(ABAC) 모드를 사용하면 로컬 파일을 사용하여 정책을 구성할 수 있다.
--authorization-mode=RBAC 역할 기반 접근 제어(RBAC) 모드를 사용하면 쿠버네티스 API를 사용하여 정책을 만들고 저장할 수 있다.
--authorization-mode=Webhook WebHook은 원격 REST 엔드포인트를 사용하여 인가를 관리할 수 있는 HTTP 콜백 모드다.
--authorization-mode=Node 노드 인가는 kubelet이 생성한 API 요청을 특별히 인가시키는 특수 목적 인가 모드다.
--authorization-mode=AlwaysDeny 이 플래그는 모든 요청을 차단한다. 이 플래그는 테스트에만 사용한다.
--authorization-mode=AlwaysAllow 이 플래그는 모든 요청을 허용한다. API 요청에 대한 인가가 필요하지 않은 경우에만 이 플래그를 사용한다.
하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에
우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다.
파드 생성을 통한 권한 확대
네임스페이스에서 파드를 생성할 수 있는 권한을 가진 사용자는
해당 네임스페이스 안에서 자신의 권한을 확대할 가능성이 있다.
네임스페이스에서 자신의 권한에 접근할 수 있는 파드를 만들 수 있다.
사용자가 스스로 읽을 수 없는 시크릿에 접근할 수 있는 파드나
서로 다른/더 큰 권한을 가진 서비스 어카운트로 실행되는 파드를 생성할 수 있다.
주의: 시스템 관리자는 파드 생성에 대한 접근 권한을 부여할 때 주의한다.
네임스페이스에서 파드(또는 파드를 생성하는 컨트롤러)를 생성할 수 있는 권한을 부여받은 사용자는
네임스페이스의 모든 시크릿을 읽을 수 있으며 네임스페이스의 모든 컨피그 맵을 읽을 수 있고
네임스페이스의 모든 서비스 어카운트를 가장하고 해당 어카운트가 취할 수 있는 모든 작업을 취할 수 있다.
이는 인가 모드에 관계없이 적용된다.
제품 보안 위원회 구성원의 GPG 키를 사용하여 이 목록으로 이메일을 암호화할 수 있다. GPG를 사용한 암호화는 공개할 필요가 없다.
언제 취약점을 보고해야 하는가?
쿠버네티스에서 잠재적인 보안 취약점을 발견했다고 생각하는 경우
취약성이 쿠버네티스에 어떤 영향을 미치는지 확신할 수 없는 경우
쿠버네티스가 의존하는 다른 프로젝트에서 취약점을 발견한 경우
자체 취약성 보고 및 공개 프로세스가 있는 프로젝트의 경우 직접 보고한다.
언제 취약점을 보고하지 말아야 하는가?
보안을 위해 쿠버네티스 구성요소를 조정하는데 도움이 필요한 경우
보안 관련 업데이트를 적용하는 데 도움이 필요한 경우
보안 관련 문제가 아닌 경우
보안 취약점 대응
각 보고서는 제품 보안 위원회 위원들에 의해 작업일 3일 이내에 인정되고 분석된다. 이렇게 하면 보안 릴리스 프로세스가 시작된다.
제품 보안 위원회와 공유하는 모든 취약성 정보는 쿠버네티스 프로젝트 내에 있으며, 문제를 해결할 필요가 없는 한 다른 프로젝트에 전파되지 않는다.
보안 문제가 심사에서 확인된 수정, 릴리스 계획으로 이동함에 따라 리포터를 계속 업데이트할 것이다.
공개 시기
공개 날짜는 쿠버네티스 제품 보안 위원회와 버그 제출자가 협상한다. 사용자 완화가 가능해지면 가능한 빨리 버그를 완전히 공개하는 것이 좋다. 버그 또는 픽스가 아직 완전히 이해되지 않았거나 솔루션이 제대로 테스트되지 않았거나 벤더 협력을 위해 공개를 지연시키는 것이 합리적이다. 공개 기간은 즉시(특히 이미 공개적으로 알려진 경우)부터 몇 주까지입니다. 간단한 완화 기능이 있는 취약점의 경우 보고 날짜부터 공개 날짜까지는 7일 정도 소요될 것으로 예상된다. 쿠버네티스 제품 보안 위원회는 공개 날짜를 설정할 때 최종 결정권을 갖는다.
6.5 - 설치 도구
6.5.1 - Kubeadm
Kubeadm은 쿠버네티스 클러스터 생성을 위한 모범 사례의 "빠른 경로"로 kubeadm init 과 kubeadm join 을 제공하도록 만들어진 도구이다.
kubeadm은 실행 가능한 최소 클러스터를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계 상, 시스템 프로비저닝이 아닌 부트스트랩(bootstrapping)만 다룬다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드별 애드온과 같은 다양한 있으면 좋은(nice-to-have) 애드온을 설치하는 것은 범위에 포함되지 않는다.
대신, 우리는 더 높은 수준의 맞춤형 도구가 kubeadm 위에 구축될 것으로 기대하며, 이상적으로는, 모든 배포의 기반으로 kubeadm을 사용하면 규격을 따르는 클러스터를 더 쉽게 생성할 수 있다.
Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다.
구성을 위해, kubectl 은 config 파일을 $HOME/.kube 에서 찾는다.
KUBECONFIG 환경 변수를 설정하거나 --kubeconfig
플래그를 설정하여 다른 kubeconfig
파일을 지정할 수 있다.
이 개요는 kubectl 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다.
지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은
kubectl 참조 문서를 참고한다.
설치 방법에 대해서는 kubectl 설치를 참고한다.
구문
터미널 창에서 kubectl 명령을 실행하려면 다음의 구문을 사용한다.
kubectl [command][TYPE][NAME][flags]
다음은 command, TYPE, NAME 과 flags 에 대한 설명이다.
command: 하나 이상의 리소스에서 수행하려는 동작을 지정한다.
예: create, get, describe, delete
TYPE: 리소스 타입을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며
단수형, 복수형 또는 약어 형식을 지정할 수 있다.
예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
NAME: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: kubectl get pods
여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다.
타입 및 이름으로 리소스를 지정하려면 다음을 참고한다.
리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. TYPE1 name1 name2 name<#> 예: kubectl get pod example-pod1 example-pod2
여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#> 예: kubectl get pod/example-pod1 replicationcontroller/example-rc1
하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. -f file1 -f file2 -f file<#>
YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, JSON 대신 YAML을 사용한다. 예: kubectl get -f ./pod.yaml
flags: 선택적 플래그를 지정한다. 예를 들어, -s 또는 --server 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.
주의: 커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다.
도움이 필요하다면, 터미널 창에서 kubectl help 를 실행한다.
명령어
다음 표에는 모든 kubectl 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.
명령어
구문
설명
alpha
kubectl alpha SUBCOMMAND [flags]
쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다.
annotate
kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]
하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다.
api-resources
kubectl api-resources [flags]
사용 가능한 API 리소스를 나열한다.
api-versions
kubectl api-versions [flags]
사용 가능한 API 버전을 나열한다.
apply
kubectl apply -f FILENAME [flags]
파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다.
attach
kubectl attach POD -c CONTAINER [-i] [-t] [flags]
실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다.
auth
kubectl auth [flags] [options]
승인을 검사한다.
autoscale
kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]
레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다.
certificate
kubectl certificate SUBCOMMAND [options]
인증서 리소스를 수정한다.
cluster-info
kubectl cluster-info [flags]
클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
completion
kubectl completion SHELL [options]
지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
config
kubectl config SUBCOMMAND [flags]
kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
convert
kubectl convert -f FILENAME [options]
다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다.
이 예제에서, 다음의 명령은 단일 파드에 대한 세부 정보를 YAML 형식의 오브젝트로 출력한다.
kubectl get pod web-pod-13je7 -o yaml
기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은
kubectl 참조 문서를 참고한다.
사용자 정의 열
사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, custom-columns 옵션을 사용할 수 있다.
사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. -o custom-columns=<spec> 또는 -o custom-columns-file=<filename>
예제
인라인:
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
템플릿 파일:
kubectl get pods <pod-name> -o custom-columns-file=template.txt
template.txt 파일에 포함된 내용은 다음과 같다.
NAME RSRC
metadata.name metadata.resourceVersion
두 명령 중 하나를 실행한 결과는 다음과 비슷하다.
NAME RSRC
submit-queue 610995
서버측 열
kubectl 는 서버에서 오브젝트에 대한 특정 열 정보 수신을 지원한다.
이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다.
이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다.
이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면,
kubectl get 명령에 --server-print=false 플래그를 추가한다.
예제
파드 상태에 대한 정보를 출력하려면, 다음과 같은 명령을 사용한다.
kubectl get pods <pod-name> --server-print=false
출력 결과는 다음과 비슷하다.
NAME AGE
pod-name 1m
오브젝트 목록 정렬
터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 kubectl 명령에 --sort-by 플래그를 추가할 수 있다. --sort-by 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, jsonpath 표현식을 사용한다.
# example-service.yaml의 정의를 사용하여 서비스를 생성한다.
kubectl apply -f example-service.yaml
# example-controller.yaml의 정의를 사용하여 레플리케이션 컨트롤러를 생성한다.
kubectl apply -f example-controller.yaml
# <directory> 디렉터리 내의 .yaml, .yml 또는 .json 파일에 정의된 오브젝트를 생성한다.
kubectl apply -f <directory>
kubectl get - 하나 이상의 리소스를 나열한다.
# 모든 파드를 일반 텍스트 출력 형식으로 나열한다.
kubectl get pods
# 모든 파드를 일반 텍스트 출력 형식으로 나열하고 추가 정보(예: 노드 이름)를 포함한다.
kubectl get pods -o wide
# 지정된 이름의 레플리케이션 컨트롤러를 일반 텍스트 출력 형식으로 나열한다. 팁: 'replicationcontroller' 리소스 타입을 'rc'로 짧게 바꿔쓸 수 있다.
kubectl get replicationcontroller <rc-name>
# 모든 레플리케이션 컨트롤러와 서비스를 일반 텍스트 출력 형식으로 함께 나열한다.
kubectl get rc,services
# 모든 데몬 셋을 일반 텍스트 출력 형식으로 나열한다.
kubectl get ds
# 노드 server01에서 실행 중인 모든 파드를 나열한다.
kubectl get pods --field-selector=spec.nodeName=server01
kubectl describe - 초기화되지 않은 리소스를 포함하여 하나 이상의 리소스의 기본 상태를 디폴트로 표시한다.
# 노드 이름이 <node-name>인 노드의 세부 사항을 표시한다.
kubectl describe nodes <node-name>
# 파드 이름이 <pod-name> 인 파드의 세부 정보를 표시한다.
kubectl describe pods/<pod-name>
# 이름이 <rc-name>인 레플리케이션 컨트롤러가 관리하는 모든 파드의 세부 정보를 표시한다.# 기억하기: 레플리케이션 컨트롤러에서 생성된 모든 파드에는 레플리케이션 컨트롤러 이름이 접두사로 붙는다.
kubectl describe pods <rc-name>
# 모든 파드의 정보를 출력한다.
kubectl describe pods
참고:kubectl get 명령은 일반적으로 동일한 리소스 타입의 하나 이상의
리소스를 검색하는 데 사용된다. 예를 들어, -o 또는 --output 플래그를
사용하여 출력 형식을 사용자 정의할 수 있는 풍부한 플래그 세트가 있다.
-w 또는 --watch 플래그를 지정하여 특정 오브젝트에 대한 업데이트 진행과정을 확인할 수
있다. kubectl describe 명령은 지정된 리소스의 여러 관련 측면을
설명하는 데 더 중점을 둔다. API 서버에 대한 여러 API 호출을 호출하여
사용자에 대한 뷰(view)를 빌드할 수 있다. 예를 들어, kubectl describe node
명령은 노드에 대한 정보뿐만 아니라, 노드에서 실행 중인 파드의 요약 정보, 노드에 대해 생성된 이벤트 등의
정보도 검색한다.
kubectl delete - 파일, 표준입력 또는 레이블 선택기, 이름, 리소스 선택기나 리소스를 지정하여 리소스를 삭제한다.
# pod.yaml 파일에 지정된 타입과 이름을 사용하여 파드를 삭제한다.
kubectl delete -f pod.yaml
# '<label-key>=<label-value>' 레이블이 있는 모든 파드와 서비스를 삭제한다.
kubectl delete pods,services -l <label-key>=<label-value>
# 초기화되지 않은 파드를 포함한 모든 파드를 삭제한다.
kubectl delete pods --all
kubectl exec - 파드의 컨테이너에 대해 명령을 실행한다.
# 파드 <pod-name>에서 'date'를 실행한 결과를 얻는다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec <pod-name> -- date
# 파드 <pod-name>의 <container-name> 컨테이너에서 'date'를 실행하여 출력 결과를 얻는다.
kubectl exec <pod-name> -c <container-name> -- date
# 파드 <pod-name>에서 대화식 TTY를 연결해 /bin/bash를 실행한다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec -ti <pod-name> -- /bin/bash
kubectl logs - 파드의 컨테이너에 대한 로그를 출력한다.
# 파드 <pod-name>에서 로그의 스냅샷을 반환한다.
kubectl logs <pod-name>
# 파드 <pod-name>에서 로그 스트리밍을 시작한다. 이것은 리눅스 명령 'tail -f'와 비슷하다.
kubectl logs -f <pod-name>
# 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로# 시작하도록 실행 파일의 이름을 지정한다.
cat ./kubectl-hello
#!/bin/sh
# 이 플러그인은 "hello world"라는 단어를 출력한다echo"hello world"
작성한 플러그인을 실행 가능하게 한다
chmod a+x ./kubectl-hello
# 그리고 PATH의 위치로 옮긴다
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin
# 이제 kubectl 플러그인을 만들고 "설치했다".# kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다
kubectl hello
hello world
# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여,# 플러그인을 "제거"할 수 있다
sudo rm /usr/local/bin/kubectl-hello
kubectl 에 사용할 수 있는 모든 플러그인을 보려면,
kubectl plugin list 하위 명령을 사용한다.
kubectl plugin list
출력 결과는 다음과 비슷하다.
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
kubectl plugin list 는 또한 실행 가능하지 않거나,
다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다.
sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거
kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar
error: one plugin warning was found
플러그인은 기존 kubectl 명령 위에 보다 복잡한 기능을
구축하는 수단으로 생각할 수 있다.
cat ./kubectl-whoami
다음 몇 가지 예는 이미 kubectl-whoami 에
다음 내용이 있다고 가정한다.
#!/bin/bash
# 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한# 정보를 출력하기 위해 'kubectl config' 명령을 사용한다.
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한
사용자가 포함된 출력이 제공된다.
# 파일을 실행 가능하게 한다
sudo chmod +x ./kubectl-whoami
# 그리고 PATH로 옮긴다
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
JSONPath 템플릿은 중괄호 {}로 둘러싸인 JSONPath 표현식으로 구성된다.
Kubectl은 JSONPath 표현식을 사용하여 JSON 오브젝트의 특정 필드를 필터링하고 출력 형식을 지정한다.
원본 JSONPath 템플릿 구문 외에도 다음과 같은 기능과 구문이 유효하다.
큰따옴표를 사용하여 JSONPath 표현식 내부의 텍스트를 인용한다.
목록을 반복하려면 range, end 오퍼레이터를 사용한다.
목록에서 뒤로 이동하려면 negative slice 인덱스를 사용한다. negative 인덱스는 목록을 "순환(wrap around)" 하지 않으며, -index + listLength >= 0 인 한 유효하다.
kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
참고:
윈도우에서 공백이 포함된 JSONPath 템플릿을 큰따옴표(위의 bash에 표시된 작은따옴표가 아님)로 묶어야 한다. 즉, 템플릿의 모든 문자 주변에 작은따옴표 또는 이스케이프된 큰따옴표를 사용해야 한다. 예를 들면, 다음과 같다.
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
참고:
JSONPath 정규식은 지원되지 않는다. 정규 표현식을 이용해 매치하려면 jq와 같은 도구를 사용하면 된다.
# kubectl은 JSONPath 출력에 대한 정규 표현식을 지원하지 않는다.# 다음 커맨드는 작동하지 않는다.
kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}'# 다음 커맨드는 원하는 결과를 얻는다.
kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image'
kubectl wait - 실험적(experimental) 기능: 하나 이상의 리소스에 대해서 특정 조건이 만족될 때까지 대기(wait)
6.6.4 - kubectl 사용 규칙
kubectl에 대한 권장 사용 규칙.
재사용 가능한 스크립트에서 kubectl 사용
스크립트의 안정적인 출력을 위해서
-o name, -o json, -o yaml, -o go-template 혹은 -o jsonpath와 같은 머신 지향(machine-oriented) 출력 양식 중 하나를 요청한다.
예를 들어 jobs.v1.batch/myjob과 같이 전체 버전을 사용한다. 이를 통해 kubectl이 시간이 지남에 따라 변경될 수 있는 기본 버전을 사용하지 않도록 한다.
문맥, 설정 또는 기타 암묵적 상태에 의존하지 않는다.
모범 사례
kubectl run
kubectl run으로 infrastructure as code를 충족시키기 위해서
버전이 명시된 태그로 이미지를 태그하고 그 태그를 새로운 버전으로 이동하지 않는다. 예를 들어, :latest가 아닌 :v1234, v1.2.3, r03062016-1-4를 사용한다(자세한 정보는 구성 모범 사례를 참고한다).
많은 파라미터가 적용된 이미지를 위한 스크립트를 작성한다.
필요하지만 kubectl run 플래그를 통해 표현할 수 없는 기능은 구성 파일을 소스 코드 버전 관리 시스템에 넣어서 전환한다.
--dry-run 플래그를 사용하여 실제로 제출하지 않고 클러스터로 보낼 오브젝트를 미리 볼 수 있다.
참고: 모든 kubectl run의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 목록 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.
생성기
kubectl create --dry-run -o yaml라는 kubectl 커맨드를 통해 다음과 같은 리소스를 생성할 수 있다.
clusterrole: 클러스터롤(ClusterRole)를 생성한다.
clusterrolebinding: 특정 클러스터롤에 대한 클러스터롤바인딩(ClusterRoleBinding)을 생성한다.
configmap: 로컬 파일, 디렉토리 또는 문자 그대로의 값으로 컨피그맵(ConfigMap)을 생성한다.
cronjob: 지정된 이름으로 크론잡(CronJob)을 생성한다.
deployment: 지정된 이름으로 디플로이먼트(Deployment)를 생성한다.
job: 지정된 이름으로 잡(Job)을 생성한다.
namespace: 지정된 이름으로 네임스페이스(Namespace)를 생성한다.
poddisruptionbudget: 지정된 이름으로 PodDisruptionBudget을 생성한다.
priorityclass: 지정된 이름으로 프라이어리티클래스(PriorityClass)을 생성한다.
quota: 지정된 이름으로 쿼터(Quota)를 생성한다.
role: 단일 규칙으로 롤(Role)을 생성한다.
rolebinding: 특정 롤 또는 클러스터롤에 대한 롤바인딩(RoleBinding)을 생성한다.
secret: 지정된 하위 커맨드를 사용하여 시크릿(Secret)을 생성한다.
service: 지정된 하위 커맨드를 사용하여 서비스(Service)를 생성한다.
serviceaccount: 지정된 이름으로 서비스어카운트(ServiceAccount)을 생성한다.
kubectl apply
kubectl apply를 사용해서 리소스를 생성하거나 업데이트 할 수 있다. kubectl apply를 사용하여 리소스를 업데이트하는 방법에 대한 자세한 정보는 Kubectl 책을 참고한다.
6.6.5 - kubectl 치트 시트
이 페이지는 일반적으로 사용하는 kubectl 커맨드와 플래그에 대한 목록을 포함한다.
Kubectl 자동 완성
BASH
source <(kubectl completion bash)# bash-completion 패키지를 먼저 설치한 후, bash의 자동 완성을 현재 셸에 설정한다echo"source <(kubectl completion bash)" >> ~/.bashrc # 자동 완성을 bash 셸에 영구적으로 추가한다
또한, kubectl의 의미로 사용되는 약칭을 사용할 수 있다.
aliask=kubectl
complete -F __start_kubectl k
ZSH
source <(kubectl completion zsh)# 현재 셸에 zsh의 자동 완성 설정echo"[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다.
kubectl config view # 병합된 kubeconfig 설정을 표시한다.# 동시에 여러 kubeconfig 파일을 사용하고 병합된 구성을 확인한다KUBECONFIG=~/.kube/config:~/.kube/kubconfig2
kubectl config view
# e2e 사용자의 암호를 확인한다
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
kubectl config view -o jsonpath='{.users[].name}'# 첫 번째 사용자 출력
kubectl config view -o jsonpath='{.users[*].name}'# 사용자 리스트 조회
kubectl config get-contexts # 컨텍스트 리스트 출력
kubectl config current-context # 현재 컨텍스트 출력
kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정# 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
# 해당 컨텍스트에서 모든 후속 kubectl 커맨드에 대한 네임스페이스를 영구적으로 저장한다
kubectl config set-context --current --namespace=ggckad-s2
# 특정 사용자와 네임스페이스를 사용하는 컨텍스트 설정
kubectl config set-context gce --user=cluster-admin --namespace=foo \
&& kubectl config use-context gce
kubectl config unset users.foo # foo 사용자 삭제
Kubectl apply
apply는 쿠버네티스 리소스를 정의하는 파일을 통해 애플리케이션을 관리한다. kubectl apply를 실행하여 클러스터에 리소스를 생성하고 업데이트한다. 이것은 프로덕션 환경에서 쿠버네티스 애플리케이션을 관리할 때 권장된다. Kubectl Book을 참고한다.
오브젝트 생성
쿠버네티스 매니페스트는 JSON이나 YAML로 정의된다. 파일 확장자는 .yaml
, .yml, .json 이 사용된다.
kubectl apply -f ./my-manifest.yaml # 리소스(들) 생성
kubectl apply -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성
kubectl apply -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생성
kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작# "Hello World"를 출력하는 잡(Job) 생성
kubectl create job hello --image=busybox -- echo"Hello World"# 매분마다 "Hello World"를 출력하는 크론잡(CronJob) 생성
kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo"Hello World"
kubectl explain pods # 파드 매니페스트 문서를 조회# stdin으로 다수의 YAML 오브젝트 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000000"
---
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000"
EOF# 여러 개의 키로 시크릿 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: $(echo -n "s33msi4" | base64 -w0)
username: $(echo -n "jane" | base64 -w0)
EOF
리소스 조회 및 찾기
# 기본 출력을 위한 Get 커맨드
kubectl get services # 네임스페이스 내 모든 서비스의 목록 조회
kubectl get pods --all-namespaces # 모든 네임스페이스 내 모든 파드의 목록 조회
kubectl get pods -o wide # 해당하는 네임스페이스 내 모든 파드의 상세 목록 조회
kubectl get deployment my-dep # 특정 디플로이먼트의 목록 조회
kubectl get pods # 네임스페이스 내 모든 파드의 목록 조회
kubectl get pod my-pod -o yaml # 파드의 YAML 조회# 상세 출력을 위한 Describe 커맨드
kubectl describe nodes my-node
kubectl describe pods my-pod
# Name으로 정렬된 서비스의 목록 조회
kubectl get services --sort-by=.metadata.name
# 재시작 횟수로 정렬된 파드의 목록 조회
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'# PersistentVolumes을 용량별로 정렬해서 조회
kubectl get pv --sort-by=.spec.capacity.storage
# app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회
kubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'# 예를 들어 'ca.crt'와 같이 점이 있는 키값을 검색한다
kubectl get configmap myconfig \
-o jsonpath='{.data.ca\.crt}'# 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/master'# 으로 명명된 라벨의 결과를 제외)
kubectl get node --selector='!node-role.kubernetes.io/master'# 네임스페이스의 모든 실행 중인 파드를 조회
kubectl get pods --field-selector=status.phase=Running
# 모든 노드의 외부IP를 조회
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'# 특정 RC에 속해있는 파드 이름의 목록 조회# "jq" 커맨드는 jsonpath를 사용하는 매우 복잡한 변환에 유용하다. https://stedolan.github.io/jq/ 에서 확인할 수 있다.sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}echo$(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})# 모든 파드(또는 레이블을 지원하는 다른 쿠버네티스 오브젝트)의 레이블 조회
kubectl get pods --show-labels
# 어떤 노드가 준비됐는지 확인JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}'\
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"# 외부 도구 없이 디코딩된 시크릿 출력
kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'# 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
# 모든 파드의 초기화 컨테이너(initContainer)의 컨테이너ID 목록 조회# 초기화 컨테이너(initContainer)를 제거하지 않고 정지된 모든 컨테이너를 정리할 때 유용하다.
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
# 타임스탬프로 정렬된 이벤트 목록 조회
kubectl get events --sort-by=.metadata.creationTimestamp
# 매니페스트가 적용된 경우 클러스터의 현재 상태와 클러스터의 상태를 비교한다.
kubectl diff -f ./my-manifest.yaml
# 노드에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.# 복잡한 중첩 JSON 구조 내에서 키를 찾을 때 유용하다.
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'# 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
리소스 업데이트
kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트
kubectl rollout history deployment/frontend # 현 리비전을 포함한 디플로이먼트의 이력을 체크
kubectl rollout undo deployment/frontend # 이전 디플로이먼트로 롤백
kubectl rollout undo deployment/frontend --to-revision=2# 특정 리비전으로 롤백
kubectl rollout status -w deployment/frontend # 완료될 때까지 "frontend" 디플로이먼트의 롤링 업데이트 상태를 감시
kubectl rollout restart deployment/frontend # "frontend" 디플로이먼트의 롤링 재시작
cat pod.json | kubectl replace -f - # std로 전달된 JSON을 기반으로 파드 교체# 리소스를 강제 교체, 삭제 후 재생성함. 이것은 서비스를 중단시킴.
kubectl replace --force -f ./pod.json
# 복제된 nginx를 위한 서비스를 생성한다. 80 포트로 서비스하고, 컨테이너는 8000 포트로 연결한다.
kubectl expose rc nginx --port=80 --target-port=8000# 단일-컨테이너 파드의 이미지 버전(태그)을 v4로 업데이트
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label=awesome # 레이블 추가
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 어노테이션 추가
kubectl autoscale deployment foo --min=2 --max=10# 디플로이먼트 "foo" 오토스케일
리소스 패치
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'# 노드를 부분적으로 업데이트# 컨테이너의 이미지를 업데이트. 병합(merge) 키이므로, spec.containers[*].name이 필요.
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'# 위치 배열을 이용한 json 패치를 사용하여, 컨테이너의 이미지를 업데이트.
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'# 위치 배열을 이용한 json 패치를 사용하여 livenessProbe 디플로이먼트 비활성화.
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'# 위치 배열에 새 요소 추가
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
리소스 편집
편집기로 모든 API 리소스를 편집.
kubectl edit svc/docker-registry # docker-registry라는 서비스 편집KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 다른 편집기 사용
리소스 스케일링
kubectl scale --replicas=3 rs/foo # 'foo'라는 레플리카셋을 3으로 스케일
kubectl scale --replicas=3 -f foo.yaml # "foo.yaml"에 지정된 리소스의 크기를 3으로 스케일
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # mysql이라는 디플로이먼트의 현재 크기가 2인 경우, mysql을 3으로 스케일
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 여러 개의 레플리케이션 컨트롤러 스케일
리소스 삭제
kubectl delete -f ./pod.json # pod.json에 지정된 유형 및 이름을 사용하여 파드 삭제
kubectl delete pod,service baz foo # "baz", "foo"와 동일한 이름을 가진 파드와 서비스 삭제
kubectl delete pods,services -l name=myLabel # name=myLabel 라벨을 가진 파드와 서비스 삭제
kubectl delete pods,services -l name=myLabel --include-uninitialized # 초기화되지 않은 것을 포함하여, name=myLabel 라벨을 가진 파드와 서비스 삭제
kubectl -n my-ns delete pod,svc --all # 초기화되지 않은 것을 포함하여, my-ns 네임스페이스 내 모든 파드와 서비스 삭제# awk pattern1 또는 pattern2에 매칭되는 모든 파드 삭제
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
실행 중인 파드와 상호 작용
kubectl logs my-pod # 파드 로그 덤프 (stdout)
kubectl logs -l name=myLabel # name이 myLabel인 파드 로그 덤프 (stdout)
kubectl logs my-pod --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout)
kubectl logs my-pod -c my-container # 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
kubectl logs -l name=myLabel -c my-container # name이 myLabel인 파드 로그 덤프 (stdout)
kubectl logs my-pod -c my-container --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
kubectl logs -f my-pod # 실시간 스트림 파드 로그(stdout)
kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행
kubectl run nginx --image=nginx -n
mynamespace # 특정 네임스페이스에서 nginx 파드 실행
kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
--dry-run=client -o yaml > pod.yaml
kubectl attach my-pod -i # 실행 중인 컨테이너에 연결
kubectl port-forward my-pod 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달
kubectl exec my-pod -- ls / # 기존 파드에서 명령 실행(한 개 컨테이너 경우)
kubectl exec --stdin --tty my-pod -- /bin/sh # 실행 중인 파드로 대화형 셸 액세스(1 컨테이너 경우)
kubectl exec my-pod -c my-container -- ls / # 기존 파드에서 명령 실행(멀티-컨테이너 경우)
kubectl top pod POD_NAME --containers # 특정 파드와 해당 컨테이너에 대한 메트릭 표시
kubectl top pod POD_NAME --sort-by=cpu # 지정한 파드에 대한 메트릭을 표시하고 'cpu' 또는 'memory'별로 정렬
디플로이먼트, 서비스와 상호 작용
kubectl logs deploy/my-deployment # 디플로이먼트에 대한 파드 로그 덤프 (단일-컨테이너 경우)
kubectl logs deploy/my-deployment -c my-container # 디플로이먼트에 대한 파드 로그 덤프 (멀티-컨테이너 경우)
kubectl port-forward svc/my-service 5000# 로컬 머신의 5000번 포트를 리스닝하고, my-service의 동일한(5000번) 포트로 전달
kubectl port-forward svc/my-service 5000:my-service-port # 로컬 머신의 5000번 포트를 리스닝하고, my-service의 <my-service-port> 라는 이름을 가진 포트로 전달
kubectl port-forward deploy/my-deployment 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, <my-deployment> 에 의해 생성된 파드의 6000번 포트로 전달
kubectl exec deploy/my-deployment -- ls # <my-deployment> 에 의해 생성된 첫번째 파드의 첫번째 컨테이너에 명령어 실행 (단일- 또는 다중-컨테이너 경우)
노드, 클러스터와 상호 작용
kubectl cordon my-node # my-node를 스케줄링할 수 없도록 표기
kubectl drain my-node # 유지 보수를 위해서 my-node를 준비 상태로 비움
kubectl uncordon my-node # my-node를 스케줄링할 수 있도록 표기
kubectl top node my-node # 주어진 노드에 대한 메트릭 표시
kubectl cluster-info # 마스터 및 서비스의 주소 표시
kubectl cluster-info dump # 현재 클러스터 상태를 stdout으로 덤프
kubectl cluster-info dump --output-directory=/path/to/cluster-state # 현재 클러스터 상태를 /path/to/cluster-state으로 덤프# key와 effect가 있는 테인트(taint)가 이미 존재하면, 그 값이 지정된 대로 대체된다.
kubectl taint nodes foo dedicated=special-user:NoSchedule
kubectl api-resources --namespaced=true# 네임스페이스를 가지는 모든 리소스
kubectl api-resources --namespaced=false# 네임스페이스를 가지지 않는 모든 리소스
kubectl api-resources -o name # 모든 리소스의 단순한 (리소스 이름만) 출력
kubectl api-resources -o wide # 모든 리소스의 확장된 ("wide"로 알려진) 출력
kubectl api-resources --verbs=list,get # "list"와 "get"의 요청 동사를 지원하는 모든 리소스 출력
kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 리소스
출력 형식 지정
특정 형식으로 터미널 창에 세부 사항을 출력하려면, 지원되는 kubectl 명령에 -o (또는 --output) 플래그를 추가한다.
# 클러스터에서 실행 중인 모든 이미지
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'# `default` 네임스페이스의 모든 이미지를 파드별로 그룹지어 출력
kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"# "k8s.gcr.io/coredns:1.6.2" 를 제외한 모든 이미지
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'# 이름에 관계없이 메타데이터 아래의 모든 필드
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app
kubectl:
# nginx 실행하는 파드를 시작한다
kubectl create deployment --image=nginx nginx-app
deployment.apps/nginx-app created
# nginx-app 에 env를 추가한다
kubectl set env deployment/nginx-app DOMAIN=cluster
deployment.apps/nginx-app env updated
참고:kubectl 커맨드는 생성되거나 변경된 리소스의 유형과 이름을 출력하므로, 이를 후속 커맨드에 사용할 수 있다. 디플로이먼트가 생성된 후에는 새로운 서비스를 노출할 수 있다.
# 서비스를 통해 포트를 노출
kubectl expose deployment nginx-app --port=80 --name=nginx-http
service "nginx-http" exposed
kubectl을 사용하면, N개의 파드가 nginx를 실행하도록 디플로이먼트를 생성할 수 있다. 여기서 N은 스펙에 명시된 레플리카 수이며, 기본값은 1이다. 또한 파드의 레이블과 셀럭터를 사용하여 서비스를 생성할 수 있다. 자세한 내용은 클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기를 참고한다.
기본적으로 이미지는 docker run -d ... 와 비슷하게 백그라운드로 실행된다. 포그라운드로 실행하려면 kubectl run을 이용하여 파드를 생성한다.
kubectl run [-i][--tty] --attach <name> --image=<image>
docker run ... 과 달리 --attach 를 지정하면 표준 입력(stdin), 표준 출력(stdout) 및 표준 오류(stderr)가 붙는다. 연결된(attached) 스트림을 제어할 수 없다(docker -a ...).
해당 컨테이너에서 분리(detach)하려면 이스케이프 시퀀스(escape sequence) Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14636241935f ubuntu:16.04 "echo test" 5 seconds ago Exited (0) 5 seconds ago cocky_fermi
55c103fa1296 nginx "nginx -g 'daemon of…" About a minute ago Up About a minute 0.0.0.0:80->80/tcp nginx-app
kubectl:
kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-app-8df569cb7-4gd89 1/1 Running 0 3m
ubuntu 0/1 Completed 0 20s
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp nginx-app
docker attach 55c103fa1296
...
kubectl:
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
kubectl attach -it nginx-app-5jyvm
...
컨테이너에서 분리하려면 이스케이프 시퀀스 Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 6 minutes ago Up 6 minutes 0.0.0.0:80->80/tcp nginx-app
docker exec 55c103fa1296 cat /etc/hostname
55c103fa1296
kubectl:
kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
파드와 컨테이너에는 근소한 차이가 있다. 기본적으로 파드는 프로세스가 종료되어도 종료되지 않는다. 대신 파드가 프로세스를 다시 시작한다. 이는 도커의 실행 옵션인 --restart=always와 유사하지만, 한 가지 큰 차이점이 있다. 도커에서는 프로세스의 각 호출에 대한 출력이 연결되지만, 쿠버네티스의 경우 각 호출은 별개다. 쿠버네티스에서 이전 실행의 출력 내용을 보려면 다음을 수행한다.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a9ec34d98787 nginx "nginx -g 'daemon of" 22 hours ago Up 22 hours 0.0.0.0:80->80/tcp, 443/tcp nginx-app
docker stop a9ec34d98787
a9ec34d98787
docker rm a9ec34d98787
a9ec34d98787
kubectl:
kubectl get deployment nginx-app
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-app 1/1 1 1 2m
kubectl get po -l run=nginx-app
NAME READY STATUS RESTARTS AGE
nginx-app-2883164633-aklf7 1/1 Running 0 2m
kubectl delete deployment nginx-app
deployment "nginx-app" deleted
kubectl get po -l run=nginx-app
# 아무것도 반환하지 않는다
참고: kubectl을 사용할 때는 파드를 직접 삭제하지 않는다. 먼저 파드를 소유한 디플로이먼트를 삭제해야 한다. 만약 파드를 직접 삭제하면 디플로이먼트가 파드를 재생성할 것이다.
docker login
kubectl은 docker login와 직접적인 유사점은 없다. 프라이빗 레지스트리와 함께 쿠버네티스를 사용하려면 프라이빗 레지스트리 사용을 참고한다.
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64
Kubernetes master is running at https://203.0.113.141
KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
6.7 - 컴포넌트 도구
6.7.1 - 기능 게이트
이 페이지에는 관리자가 다른 쿠버네티스 컴포넌트에서 지정할 수 있는 다양한
기능 게이트에 대한 개요가 포함되어 있다.
기능 게이트는 쿠버네티스 기능을 설명하는 일련의 키=값 쌍이다.
각 쿠버네티스 컴포넌트에서 --feature-gates 커맨드 라인 플래그를 사용하여
이러한 기능을 켜거나 끌 수 있다.
각 쿠버네티스 컴포넌트를 사용하면 해당 컴포넌트와 관련된 기능 게이트 집합을
활성화 또는 비활성화할 수 있다.
모든 컴포넌트에 대한 전체 기능 게이트 집합을 보려면 -h 플래그를 사용한다.
kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 --feature-gates 플래그를 사용한다.
--feature-gates="...,DynamicKubeletConfig=true"
다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를
요약한 것이다.
"도입" 열에는 기능이 소개되거나 릴리스 단계가 변경될 때의
쿠버네티스 릴리스가 포함된다.
"종료" 열이 비어 있지 않으면, 여전히 기능 게이트를 사용할 수 있는 마지막
쿠버네티스 릴리스가 포함된다.
버그의 위험이 증가하고 장기 지원이 부족하여, 단기 테스트
클러스터에서만 사용하는 것이 좋다.
베타 기능은 다음을 의미한다.
기본적으로 활성화되어 있다.
이 기능은 잘 테스트되었다. 이 기능을 활성화하면 안전한 것으로 간주된다.
세부 내용은 변경될 수 있지만, 전체 기능에 대한 지원은 중단되지 않는다.
오브젝트의 스키마 및/또는 시맨틱은 후속 베타 또는 안정 릴리스에서
호환되지 않는 방식으로 변경될 수 있다. 이러한 상황이 발생하면, 다음 버전으로 마이그레이션하기 위한
지침을 제공한다. API 오브젝트를 삭제, 편집 및 재작성해야
할 수도 있다. 편집 과정에서 약간의 생각이 필요할 수 있다.
해당 기능에 의존하는 애플리케이션의 경우 다운타임이 필요할 수 있다.
후속 릴리스에서 호환되지 않는 변경이 발생할 수 있으므로
업무상 중요하지 않은(non-business-critical) 용도로만
권장한다. 독립적으로 업그레이드할 수 있는 여러 클러스터가 있는 경우, 이 제한을 완화할 수 있다.
참고:베타 기능을 사용해 보고 의견을 보내주길 바란다!
베타 기간이 종료된 후에는, 더 많은 변경을 하는 것이 실용적이지 않을 수 있다.
GA(General Availability) 기능은 안정 기능이라고도 한다. 이 의미는 다음과 같다.
이 기능은 항상 활성화되어 있다. 비활성화할 수 없다.
해당 기능 게이트는 더 이상 필요하지 않다.
여러 후속 버전의 릴리스된 소프트웨어에 안정적인 기능의 버전이 포함된다.
기능 게이트 목록
각 기능 게이트는 특정 기능을 활성화/비활성화하도록 설계되었다.
APIListChunking: API 클라이언트가 API 서버에서 (LIST 또는 GET)
리소스를 청크(chunks)로 검색할 수 있도록 한다.
APIPriorityAndFairness: 각 서버의 우선 순위와 공정성을 통해 동시 요청을
관리할 수 있다. (RequestManagement 에서 이름이 변경됨)
APIResponseCompression: LIST 또는 GET 요청에 대한 API 응답을 압축한다.
AllowExtTrafficLocalEndpoints: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다.
AllowInsecureBackendProxy: 사용자가 파드 로그 요청에서 kubelet의
TLS 확인을 건너뛸 수 있도록 한다.
AnyVolumeDataSource: PVC의
DataSource 로 모든 사용자 정의 리소스 사용을 활성화한다.
AppArmor: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다.
자세한 내용은 AppArmor 튜토리얼을 참고한다.
AttachVolumeLimit: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
대한 제한을 보고하도록 한다.
자세한 내용은 동적 볼륨 제한을 참고한다.
BalanceAttachedNodeVolumes: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를
포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가
더 가까운 노드가 선호된다.
BlockVolume: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다.
자세한 내용은 원시 블록 볼륨 지원을
참고한다.
BoundServiceAccountTokenVolume: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을
마이그레이션한다. 클러스터 관리자는 serviceaccount_stale_tokens_total 메트릭을 사용하여
확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 --service-account-extend-token-expiration=false 플래그로
kube-apiserver를 시작하여 확장 토큰 기능을 끈다.
자세한 내용은 바운드 서비스 계정 토큰을
확인한다.
CPUManager: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
CPU 관리 정책을 참고한다.
CSIBlockVolume: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다.
자세한 내용은 csi 원시 블록 볼륨 지원
문서를 참고한다.
CSIDriverRegistry: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된
모든 로직을 활성화한다.
CSIInlineVolume: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다.
CSIMigration: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서
사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다.
CSIMigrationAWS: shim 및 변환 로직을 통해 볼륨 작업을
AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에
EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로
폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다.
CSIMigrationAWSComplete: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리
플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS
인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다.
클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고
EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
CSIMigrationAzureDisk: shim 및 변환 로직을 통해 볼륨 작업을
Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리
AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가
필요하다.
CSIMigrationAzureDiskComplete: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리
플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을
Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로
라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능
플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어
있어야 한다.
CSIMigrationAzureFile: shim 및 변환 로직을 통해 볼륨 작업을
Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다.
노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가
필요하다.
CSIMigrationAzureFileComplete: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리
플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을
Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로
라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능
플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어
있어야 한다.
CSIMigrationGCE: shim 및 변환 로직을 통해 볼륨 작업을
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에
PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을
지원한다. CSIMigration 기능 플래그가 필요하다.
CSIMigrationGCEComplete: kubelet 및 볼륨 컨트롤러에서 GCE-PD
인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD
인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI
플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
CSIMigrationOpenStack: shim 및 변환 로직을 통해 볼륨 작업을
Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에
Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
CSIMigrationOpenStackComplete: kubelet 및 볼륨 컨트롤러에서
Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리
플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다.
클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고
Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
CSIMigrationvSphere: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을
라우팅하는 shim 및 변환 로직을 사용한다.
노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우
인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
CSIMigrationvSphereComplete: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리
플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서
vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및
CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이
클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
CSINodeInfo: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
ExpandPersistentVolumes: 퍼시스턴트 볼륨 확장을 활성화한다.
퍼시스턴트 볼륨 클레임 확장을 참고한다.
ExperimentalCriticalPodAnnotation: 특정 파드에 critical 로
어노테이션을 달아서 스케줄링이 보장되도록 한다.
이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
ExperimentalHostUserNamespaceDefaultingGate: 사용자 네임스페이스를 호스트로
기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,
권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: MKNODE, SYS_MODULE 등)을
사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스
재 매핑이 활성화된 경우에만 활성화해야 한다.
GCERegionalPersistentDisk: GCE에서 지역 PD 기능을 활성화한다.
GenericEphemeralVolume: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인
볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원
등에서 제공할 수 있음).
임시 볼륨을 참고한다.
GracefulNodeShutdown : kubelet에서 정상 종료를 지원한다.
시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행 중인
파드를 정상적으로 종료하려고 시도한다. 자세한 내용은
Graceful Node Shutdown을
참조한다.
HPAContainerMetrics: HorizontalPodAutoscaler를 활성화하여 대상 파드의
개별 컨테이너 메트릭을 기반으로 확장한다.
HPAScaleToZero: 사용자 정의 또는 외부 메트릭을 사용할 때 HorizontalPodAutoscaler 리소스에 대해
minReplicas 를 0으로 설정한다.
ImmutableEphemeralVolumes: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
변경할 수 없는(immutable) 것으로 표시할 수 있다.
KubeletConfigFile: 구성 파일을 사용하여 지정된 파일에서
kubelet 구성을 로드할 수 있다.
자세한 내용은 구성 파일을 통해 kubelet 파라미터 설정을
참고한다.
KubeletCredentialProviders: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다.
KubeletPluginsWatcher: kubelet이 CSI 볼륨 드라이버와 같은
플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
KubeletPodResources: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은
장치 모니터링 지원을
참고한다.
LegacyNodeRoleBehavior: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은
NodeDisruptionExclusion 과 ServiceNodeExclusion 에 의해 제공된 기능별 레이블을 대신하여
node-role.kubernetes.io/master 레이블을 무시한다.
LocalStorageCapacityIsolationFSQuotaMonitoring: 로컬 임시 스토리지에
LocalStorageCapacityIsolation 이 활성화되고
emptyDir 볼륨의
백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 파일시스템 사용보다는
프로젝트 쿼터를 사용하여 emptyDir 볼륨
스토리지 사용을 모니터링하여 성능과 정확성을
향상시킨다.
MixedProtocolLBService: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
사용을 활성화한다.
MountContainers (사용 중단됨): 호스트의 유틸리티 컨테이너를 볼륨 마운터로
사용할 수 있다.
MountPropagation: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
자세한 내용은 마운트 전파(propagation)을 참고한다.
NodeDisruptionExclusion: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 node.kubernetes.io/exclude-disruption
사용을 활성화한다.
NodeLease: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
PodReadinessGates: 파드 준비성 평가를 확장하기 위해
PodReadinessGate 필드 설정을 활성화한다. 자세한 내용은 파드의 준비성 게이트를
참고한다.
PodShareProcessNamespace: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를
공유하기 위해 파드에서 shareProcessNamespace 설정을 활성화한다. 자세한 내용은
파드의 컨테이너 간 프로세스 네임스페이스 공유에서 확인할 수 있다.
ProcMountType: SecurityContext의 procMount 필드를 설정하여
컨테이너의 proc 타입의 마운트를 제어할 수 있다.
QOSReserved: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가
더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다
(현재 메모리만 해당).
RemainingItemCount: API 서버가
청크(chunking) 목록 요청에 대한
응답에서 남은 항목 수를 표시하도록 허용한다.
RemoveSelfLink: ObjectMeta 및 ListMeta에서 selfLink 를 사용하지 않고
제거한다.
ResourceLimitsPriorityFunction (사용 중단됨): 입력 파드의 CPU 및 메모리 한도 중
하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는
스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진
노드 사이의 관계를 끊는 것이다.
ResourceQuotaScopeSelectors: 리소스 쿼터 범위 셀렉터를 활성화한다.
RootCAConfigMap: 모든 네임스페이스에 kube-root-ca.crt라는
컨피그맵을 게시하도록
kube-controller-manager 를 구성한다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데
사용되는 CA 번들이 포함되어 있다. 자세한 내용은
바운드 서비스 계정 토큰을
참조한다.
RotateKubeletClientCertificate: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다.
자세한 내용은 kubelet 구성을 참고한다.
RotateKubeletServerCertificate: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
RunAsGroup: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를
활성화한다.
StorageVersionHash: API 서버가 디스커버리에서 스토리지 버전 해시를 노출하도록
허용한다.
StreamingProxyRedirects: 스트리밍 요청을 위해 백엔드(kubelet)에서 리디렉션을
가로채서 따르도록 API 서버에 지시한다.
스트리밍 요청의 예로는 exec, attach 및 port-forward 요청이 있다.
SupportIPVSProxyMode: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다.
자세한 내용은 서비스 프록시를 참고한다.
SupportPodPidsLimit: 파드의 PID 제한을 지원한다.
SupportNodePidsLimit: 노드에서 PID 제한 지원을 활성화한다.
--system-reserved 및 --kube-reserved 옵션의 pid=<number>
파라미터를 지정하여 지정된 수의 프로세스 ID가
시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록
할 수 있다.
Sysctls: 각 파드에 설정할 수 있는 네임스페이스 커널
파라미터(sysctl)를 지원한다. 자세한 내용은
sysctl을 참고한다.
TTLAfterFinished: TTL 컨트롤러가
실행이 끝난 후 리소스를 정리하도록
허용한다.
TaintBasedEvictions: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로
노드에서 파드를 축출할 수 있다.
자세한 내용은 테인트와 톨러레이션을
참고한다.
TaintNodesByCondition: 노드 컨디션을
기반으로 자동 테인트 노드를 활성화한다.
TokenRequest: 서비스 어카운트 리소스에서 TokenRequest 엔드포인트를 활성화한다.
TokenRequestProjection: projected 볼륨을 통해
서비스 어카운트 토큰을 파드에 주입할 수 있다.
TopologyManager: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스
할당을 조정하는 메커니즘을 활성화한다.
노드의 토폴로지 관리 정책 제어를 참고한다.
VolumePVCDataSource: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다.
VolumeScheduling: 볼륨 토폴로지 인식 스케줄링을 활성화하고
퍼시스턴트볼륨클레임(PVC) 바인딩이 스케줄링 결정을 인식하도록 한다. 또한
PersistentLocalVolumes 기능 게이트와 함께 사용될 때
local 볼륨 유형을 사용할 수 있다.
VolumeSnapshotDataSource: 볼륨 스냅샷 데이터 소스 지원을 활성화한다.
VolumeSubpathEnvExpansion: 환경 변수를 subPath로 확장하기 위해
subPathExpr 필드를 활성화한다.
WarningHeaders: API 응답에서 경고 헤더를 보낼 수 있다.
WatchBookmark: 감시자 북마크(watch bookmark) 이벤트 지원을 활성화한다.
WinDSR: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다.
WinOverlay: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다.
WindowsGMSA: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다.
WindowsRunAsUserName : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서
애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은
RunAsUserName 구성을
참고한다.
WindowsEndpointSliceProxying: 활성화되면, 윈도우에서 실행되는 kube-proxy는
엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여
확장성과 성능을 향상시킨다.
엔드포인트 슬라이스 활성화하기를 참고한다.
다음 내용
사용 중단 정책은 쿠버네티스에 대한
기능과 컴포넌트를 제거하는 프로젝트의 접근 방법을 설명한다.
6.7.2 - kube-proxy
시놉시스
쿠버네티스 네트워크 프록시는 각 노드에서 실행된다.
이는 각 노드의 쿠버네티스 API에 정의된 서비스를 반영하며 단순한
TCP, UDP 및 SCTP 스트림 포워딩 또는 라운드 로빈 TCP, UDP 및 SCTP 포워딩을 백엔드 셋에서 수행 할 수 있다.
서비스 클러스트 IP 및 포트는 현재 서비스 프록시에 의해 열린 포트를 지정하는
Docker-links-compatible 환경 변수를 통해 찾을 수 있다.
이러한 클러스터 IP에 클러스터 DNS를 제공하는 선택적 애드온이 있다. 유저는 apiserver API로
서비스를 생성하여 프록시를 구성해야 한다.
kube-proxy [flags]
옵션
--azure-container-registry-config string
Azure 컨테이너 레지스트리 구성 정보가 들어 있는 파일의 경로.
--bind-address string 기본값: 0.0.0.0
프록시 서버가 서비스할 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0'으로 설정, 모든 IPv6 인터페이스의 경우 '::'로 설정)
--bind-address-hard-fail
true인 경우 kube-proxy는 포트 바인딩 실패를 치명적인 것으로 간주하고 종료한다.
--cleanup
true인 경우 iptables 및 ipvs 규칙을 제거하고 종료한다.
--cluster-cidr string
클러스터에 있는 파드의 CIDR 범위. 구성 후에는 이 범위 밖에서 서비스 클러스터 IP로 전송되는 트래픽은 마스커레이드되고 파드에서 외부 LoadBalancer IP로 전송된 트래픽은 대신 해당 클러스터 IP로 전송된다
--config string
설정 파일의 경로.
--config-sync-period duration 기본값: 15m0s
apiserver의 설정이 갱신되는 빈도. 0보다 커야 한다.
--conntrack-max-per-core int32 기본값: 32768
CPU 코어당 추적할 최대 NAT 연결 수(한도(limit)를 그대로 두고 contrack-min을 무시하려면 0으로 설정한다)(
--conntrack-min int32 기본값: 131072
conntrack-max-per-core와 관계없이 할당할 최소 conntrack 항목 수(한도를 그대로 두려면 conntrack-max-per-core값을 0으로 설정).
메트릭 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0:10249', 모든 IPv6 인터페이스의 경우 '[::]:10249'로 설정됨). 사용하지 않으려면 비워둘 것.
--nodeport-addresses stringSlice
NodePort에 사용할 주소를 지정하는 값의 문자열 조각. 값은 유효한 IP 블록(예: 1.2.3.0/24, 1.2.3.4/32). 기본값인 빈 문자열 조각값은([]) 모든 로컬 주소를 사용하는 것을 의미한다.
--oom-score-adj int32 기본값: -999
kube-proxy 프로세스에 대한 oom-score-adj 값. 값은 [-1000, 1000] 범위 내에 있어야 한다.
--profiling
값이 true이면 /debug/pprof 핸들러에서 웹 인터페이스를 통한 프로파일링을 활성화한다.
--proxy-mode ProxyMode
사용할 프록시 모드: 'userspace' (이전) or 'iptables' (빠름) or 'ipvs' or 'kernelspace' (윈도우). 공백인 경우 가장 잘 사용할 수 있는 프록시(현재는 iptables)를 사용한다. iptables 프록시를 선택했지만, 시스템의 커널 또는 iptables 버전이 맞지 않으면, 항상 userspace 프록시로 변경된다.
--proxy-port-range port-range
서비스 트래픽을 프록시하기 위해 사용할 수 있는 호스트 포트 범위(beginPort-endPort, single port 또는 beginPort+offset 포함). 만약 범위가 0, 0-0, 혹은 지정되지 않으면, 포트는 무작위로 선택된다.
--show-hidden-metrics-for-version string
숨겨진 메트릭을 표시할 이전 버전.
--udp-timeout duration 기본값: 250ms
유휴 UDP 연결이 열린 상태로 유지되는 시간(예: '250ms', '2s'). 값은 0보다 커야 한다. 프록시 모드 userspace에만 적용 가능함.
--version version[=true]
버전 정보를 인쇄하고 종료.
--write-config-to string
기본 구성 값을 이 파일에 옮겨쓰고 종료한다.
6.7.3 - Kubelet 인증/인가
개요
kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 제공하는 API를 노출하며,
노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다.
이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다.
Kubelet 인증
기본적으로, 다른 구성의 인증 방법에 의해 거부되지 않은 kubelet의 HTTPS 엔드포인트에 대한 요청은
익명의 요청으로 처리되며, system:anonymous의 사용자 이름과 system:unauthenticated
의 그룹이 부여된다.
익명의 접근을 비활성화하고 인증되지 않은 요청에 401 Unauthorized 응답을 보내려면 아래를 참고한다.
--anonymous-auth=false 플래그로 kubelet을 시작
kubelet의 HTTPS 엔드포인트에 대한 X509 클라이언트 인증서 인증을 활성화하려면 아래를 참고한다.
--client-ca-file 플래그로 kubelet을 시작하면 클라이언트 인증서를 확인할 수 있는 CA 번들을 제공
--kubelet-client-certificate 및 --kubelet-client-key 플래그로 apiserver를 시작
NoVolumeZoneConflict: 해당 스토리지에 대한 장애 영역 제한이 주어지면
파드가 요청하는 볼륨을 노드에서 사용할 수 있는지
평가한다.
NoDiskConflict: 요청하는 볼륨과 이미 마운트된 볼륨으로 인해
파드가 노드에 적합한지 평가한다.
MaxCSIVolumeCount: 연결해야 하는 CSI 볼륨의 수와
구성된 제한을 초과하는지 여부를 결정한다.
CheckNodeMemoryPressure: 노드가 메모리 압박을 보고하고 있고, 구성된
예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.
CheckNodePIDPressure: 노드가 프로세스 ID 부족을 보고하고 있고, 구성된
예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.
CheckNodeDiskPressure: 노드가 스토리지 압박(파일시스템이 가득차거나
거의 꽉 참)을 보고하고 있고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.
CheckNodeCondition: 노드는 파일시스템이 완전히 가득찼거나,
네트워킹을 사용할 수 없거나, kubelet이 파드를 실행할 준비가 되지 않았다고 보고할 수 있다.
노드에 대해 이러한 조건이 설정되고, 구성된 예외가 없는 경우, 파드가
해당 노드에 스케줄되지 않는다.
PodToleratesNodeTaints: 파드의 톨러레이션이
노드의 테인트를 용인할 수 있는지 확인한다.
CheckVolumeBinding: 파드가 요청한 볼륨에 적합할 수 있는지 평가한다.
이는 바인딩된 PVC와
바인딩되지 않은 PVC 모두에 적용된다.
LeastRequestedPriority: 요청된 리소스가 적은 노드를 선호한다. 즉,
노드에 배치되는 파드가 많고, 해당 파드가 사용하는 리소스가
많을수록 이 정책이 부여하는 순위가 낮아진다.
MostRequestedPriority: 요청된 리소스가 가장 많은 노드를 선호한다.
이 정책은 전체 워크로드 세트를 실행하는 데 필요한 최소 노드 수에 스케줄된
파드를 맞춘다.
RequestedToCapacityRatioPriority: 기본 리소스 스코어링 기능을 사용하여 ResourceAllocationPriority에 기반한 requestedToCapacity를 생성한다.
BalancedResourceAllocation: 균형 잡힌 리소스 사용의 노드를 선호한다.
NodePreferAvoidPodsPriority: 노드 어노테이션 scheduler.alpha.kubernetes.io/preferAvoidPods에 따라
노드의 우선순위를 지정한다. 이를 사용하여 두 개의 다른 파드가
동일한 노드에서 실행되면 안된다는 힌트를 줄 수 있다.
NodeAffinityPriority: PreferredDuringSchedulingIgnoredDuringExecution에 표시된 노드 어피니티 스케줄링
설정에 따라 노드의 우선순위를 지정한다.
이에 대한 자세한 내용은 노드에 파드 할당하기에서 확인할 수 있다.
TaintTolerationPriority: 노드에서 용인할 수 없는 테인트 수를 기반으로,
모든 노드의 우선순위 목록을 준비한다. 이 정책은 해당 목록을
고려하여 노드의 순위를 조정한다.
ImageLocalityPriority: 해당 파드의
컨테이너 이미지가 이미 로컬로 캐시된
노드를 선호한다.
ServiceSpreadingPriority: 특정 서비스에 대해, 이 정책은 해당 서비스에 대한
파드가 서로 다른 노드에서 실행되는 것을 목표로 한다. 해당 서비스에 대한
파드가 이미 할당되지 않은 노드에 스케줄링하는 것을 선호한다. 전반적인 결과는
서비스가 단일 노드 장애에 대해 더 탄력적이라는 것이다.
구성 파일을 작성하고 해당 경로를 커맨드 라인 인수로 전달하여
kube-scheduler 의 동작을 사용자 정의할 수 있다.
스케줄링 프로파일(Profile)을 사용하면 kube-scheduler에서
여러 단계의 스케줄링을 구성할 수 있다.
각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한
익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.
쿠버네티스 문서에 문제가 있거나, 새로운 내용에 대한 아이디어가 있으면, 이슈를 연다. GitHub 계정과 웹 브라우저만 있으면 된다.
대부분의 경우, 쿠버네티스 문서에 대한 새로운 작업은 GitHub의 이슈로 시작된다. 그런 다음
쿠버네티스 기여자는 필요에 따라 이슈를 리뷰, 분류하고 태그를 지정한다. 다음으로, 여러분이나
다른 쿠버네티스 커뮤니티 멤버가 문제를 해결하기 위한 변경 사항이 있는 풀 리퀘스트를 연다.
이슈 열기
기존 콘텐츠에 대한 개선을 제안하거나, 오류를 발견하면, 이슈를 연다.
오른쪽 사이드바에서 문서에 이슈 생성 링크를 클릭한다. 그러면 헤더가
미리 채워진 GitHub 이슈 페이지로 리디렉션된다.
개선을 위한 문제나 제안 사항을 설명한다. 가능한 한 많은 정보를 제공한다.
Submit new issue 를 클릭한다.
이슈를 제출한 후, 가끔 확인하거나 GitHub 알림을 켜자.
리뷰어와 다른 커뮤니티 멤버가 이슈에 대한 조치를 취하기 전에
여러분에게 질문을 할 수 있다.
새로운 콘텐츠 제안
새로운 콘텐츠에 대한 아이디어가 있지만, 어디로 가야 할지 확실하지 않은 경우에도
이슈를 제기할 수 있다. 다음 중 하나를 선택하면 된다.
포크의 origin/master 와 kubernetes/website 의 upstream/master 에서 커밋을 가져온다.
git fetch origin
git fetch upstream
이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다.
참고: 이 워크플로는 쿠버네티스 커뮤니티 GitHub 워크플로와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 master 복사본을 upstream/master 와 병합할 필요가 없다.
브랜치 만들기
작업할 브랜치 기반을 결정한다.
기존 콘텐츠를 개선하려면, upstream/master 를 사용한다.
기존 기능에 대한 새로운 콘텐츠를 작성하려면, upstream/master 를 사용한다.
현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 쿠버네티스 문서 현지화를 참고한다.
다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 릴리스 문서화를 참고한다.
콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는,
해당 작업을 위해 작성된 특정 기능 브랜치를
사용한다.
브랜치 선택에 도움이 필요하면, 슬랙 채널 #sig-docs 에 문의한다.
1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 upstream/master 라고 가정한다.
git checkout -b <my_new_branch> upstream/master
텍스트 편집기를 사용하여 변경한다.
언제든지, git status 명령을 사용하여 변경한 파일을 본다.
변경 사항 커밋
풀 리퀘스트를 제출할 준비가 되면, 변경 사항을 커밋한다.
로컬 리포지터리에서 커밋해야 할 파일을 확인한다.
git status
출력은 다음과 비슷하다.
On branch <my_new_branch>
Your branch is up to date with 'origin/<my_new_branch>'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory)
modified: content/en/docs/contribute/new-content/contributing-content.md
no changes added to commit (use "git add" and/or "git commit -a")
Changes not staged for commit 에 나열된 파일을 커밋에 추가한다.
git add <your_file_name>
각 파일에 대해 이 작업을 반복한다.
모든 파일을 추가한 후, 커밋을 생성한다.
git commit -m "Your commit message"
참고: 커밋 메시지에 GitHub 키워드를 사용하지 말자. 나중에 풀 리퀘스트 설명에 추가할
수 있다.
로컬 브랜치와 새로운 커밋을 원격 포크로 푸시한다.
git push origin <my_new_branch>
로컬에서 변경 사항 미리보기
변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다.
website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 Hugo 단축코드를 표시하므로, 디버깅에 유용할 수 있다.
PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. PR의 Commits 탭에서 또는 git log 명령을 로컬에서 실행하여 커밋 수를 확인할 수 있다.
참고: 여기서는 vim 을 커맨드 라인 텍스트 편집기로 사용하는 것을 가정한다.
대화식 리베이스를 시작한다.
git rebase -i HEAD~<number_of_commits_in_branch>
커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 -i 스위치는 리베이스를 대화형으로 할 수 있게 한다. HEAD~<number_of_commits_in_branch> 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
출력은 다음과 비슷하다.
pick d875112ca Original commit
pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2# 3d18sf680..7d54e15ee 를 3d183f680 으로 리베이스한다 (3개 명령)
...
# 이 행들은 순서를 바꿀 수 있다. 이들은 위에서 아래로 실행된다.
출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다. 두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다. pick 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다.
cncf-cla: yes(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 CLA 서명을 참고한다.
language/en(권장): 영어 문서에 대한 PR 전용 필터이다.
size/<size>: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다.
또한, PR이 진행 중인 작업으로 표시되지 않았는지 확인한다. work in progress 레이블을 사용하는 PR은 아직 리뷰할 준비가 되지 않은 PR이다.
리뷰할 PR을 선택한 후, 다음을 통해 변경 사항을 이해한다.
PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기
다른 리뷰어의 의견 읽기
Files changed 탭을 클릭하여 변경된 파일과 행 보기
Conversation 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 deploy/netlify 행의 Details 링크를 클릭하고 Netlify 미리보기 빌드의 변경 사항을 확인
Files changed 탭으로 이동하여 리뷰를 시작한다.
코멘트을 달려는 줄 옆에 있는 + 기호를 클릭한다.
행에 대한 의견을 작성하고 Add single comments(작성할 의견이 하나만 있는 경우) 또는 Start a review(작성할 의견이 여러 개인 경우)를 클릭한다.
완료되면, 페이지 상단에서 Review changes 를 클릭한다. 여기에서
리뷰에 대한 요약을 추가하고(기여자에게 긍정적인 의견을 남겨주기 바란다!),
PR을 승인하거나, 의견을 보내거나 필요에 따라 변경을 요청할 수 있다. 새로운 기여자는
항상 Comment 를 선택해야 한다.
매주 특정 문서 승인자 역할의 지원자가
풀 리퀘스트를 심사하고 리뷰한다. 이
사람은 일주일 동안 "PR 랭글러(Wrangler)"이다. 자세한
정보는 PR 랭글러 스케줄러를 참고한다. PR 랭글러가 되려면, 매주 SIG Docs 회의에 참석하고 자원한다. 이번 주에 해당 일정이 없는 경우에도, 아직 리뷰 중이 아닌
풀 리퀘스트(PR)를 여전히 리뷰할 수 있다.
로테이션 외에도, 봇은 영향을 받는 파일의 소유자를 기반으로
PR에 대한 리뷰어와 승인자를 할당한다.
참고: 다음 번부터는 PR을 열기 전에 작성자가 브랜치를 자신의 포크로
푸시하도록 권장한다.
PR 작성자가 승인자의 수정을 명시적으로 허용하지 않는다.
리뷰를 위한 Prow 명령
Prow는
풀 리퀘스트 (PR)에 대한 작업을 실행하는 쿠버네티스 기반 CI/CD 시스템이다. Prow는
챗봇 스타일 명령으로 쿠버네티스
조직 전체에서 레이블 추가와 제거, 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 있다. /<command-name> 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다.
이슈는 일반적으로 신속하게 열리고 닫힌다.
그러나, 가끔씩은 이슈가 열린 후 비활성 상태로 있다.
어떤 경우에는 이슈가 90일 이상 열려 있을 수도 있다.
이슈의 lifecycle 레이블
레이블
설명
lifecycle/stale
90일이 지나도 아무런 활동이 없는 이슈는 자동으로 오래된 것(stale)으로 표시된다. /remove-lifecycle stale 명령을 사용하여 라이프사이클을 수동으로 되돌리지 않으면 이슈가 자동으로 닫힌다.
lifecycle/frozen
90일 동안 활동이 없어도 이 레이블의 이슈는 오래된 것(stale)으로 바뀌지 않는다. 사용자는 priority/important-longterm 레이블이 있는 이슈처럼 90일보다 훨씬 오래 열려 있어야 하는 이슈에 이 레이블을 수동으로 추가한다.
특별한 이슈 유형의 처리
SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의 이슈를
자주 경험하게 된다.
중복된 이슈
단일 문제에 대해 하나 이상의 이슈가 열려 있으면, 이를 단일 이슈로 합친다.
열린 상태를 유지할 이슈를 결정한 다음(또는
새로운 이슈를 열어야 함), 모든 관련 정보로 이동하여 관련 이슈를 연결해야 한다.
마지막으로, 동일한 문제를 설명하는 다른 모든 이슈에
triage/duplicate 레이블을 지정하고 닫는다. 하나의 이슈만 해결하는 것으로 혼동을 줄이고
같은 문제에 대한 중복 작업을 피할 수 있다.
깨진 링크 이슈
깨진 링크 이슈가 API 문서나 kubectl 문서에 있는 경우, 문제가 완전히 이해될 때까지 /priority critical-urgent 레이블을 할당한다. 다른 모든 깨진 링크 이슈는 수동으로 수정해야하므로, /priority important-longterm 를 할당한다.
블로그 이슈
쿠버네티스 블로그 항목은 시간이 지남에 따라
구식이 될 것으로 예상한다. 따라서, 1년 미만의 블로그 항목만 유지 관리한다.
1년이 지난 블로그 항목과 관련된 이슈일 경우,
수정하지 않고 이슈를 닫는다.
지원 요청 또는 코드 버그 리포트
문서에 대한 일부 이슈는 실제로 기본 코드와 관련된 이슈이거나, 튜토리얼과
같은 무언가가 작동하지 않을 때 도움을 요청하는 것이다.
문서와 관련이 없는 이슈의 경우, triage/support 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을
알려주며 이슈를 닫고, 기능 관련 버그에 대한 이슈인 경우,
관련 리포지터리를 코멘트로 남긴다(kubernetes/kubernetes 는
시작하기 좋은 곳이다).
지원 요청에 대한 샘플 응답은 다음과 같다.
이 이슈는 지원 요청과 비슷하지만
문서 관련 이슈와는 관련이 없는 것 같습니다.
[쿠버네티스 슬랙](https://slack.k8s.io/)의
`#kubernetes-users` 채널에서 질문을 하시기 바랍니다. 또한,
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)와
같은 리소스를 검색하여 유사한 질문에 대한 답변을
얻을 수도 있습니다.
https://github.com/kubernetes/kubernetes 에서
쿠버네티스 기능 관련 이슈를 열 수도 있습니다.
문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.
샘플 코드 버그 리포트 응답은 다음과 같다.
이 이슈는 문서에 대한 이슈보다 코드에 대한 이슈와
비슷합니다. https://github.com/kubernetes/kubernetes/issues 에서
이슈를 여십시오.
문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.
SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
누구나 풀 리퀘스트(PR)를 요청할 수 있고,
누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다.
멤버,
리뷰어, 또는
승인자가 될 수 있다.
이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다.
쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
커뮤니티 멤버십
문서를 확인한다.
문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와
문서를 관리하는 책임을 가지는 SIG Docs에서,
이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다.
SIG Docs 의장
SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와
다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과
그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다.
현재 의장의 목록을 확인하려면
리더십
문서를 참조한다.
SIG Docs 팀과 자동화
SIG Docs의 자동화는 다음의 두 가지 메커니즘에 의존한다.
GitHub 팀과 OWNERS 파일이다.
GitHub 팀
GitHub의 SIG Docs [팀]에는 두 분류가 있다.
승인자와 리더를 위한 @sig-docs-{language}-owners
리뷰어를 위한 @sig-docs-{language}-reviewers
그룹의 전원과 의사소통하기 위해서
각각 GitHub 코멘트에서 그룹의 @name으로 참조할 수 있다.
가끔은 Prow와 GitHub 팀은 정확히 일치하지 않고 중복된다.
이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서
자동화 시스템이 OWNERS 파일의 정보를 활용한다.
OWNERS 파일과 전문(front-matter)
쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다.
쿠버네티스 웹사이트 리포지터리는
다음의 두개의 prow 플러그인을
사용한다.
blunderbuss
approve
이 두 플러그인은 kubernetes/website GitHub 리포지터리 최상위 수준에 있는
OWNERS와
OWNERS_ALIASES
파일을 사용해서
해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다.
OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수
있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다.
일반적인 OWNERS 파일에 대한 보다 많은 정보는
OWNERS
문서를 참고한다.
추가로, 개별 마크다운(Markdown) 파일 내 전문에
리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다.
OWNERS 파일과 마크다운 파일 내 전문의 조합은
자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를
PR 소유자에게 조언하는데 활용된다.
병합 작업 방식
풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는
브랜치에 병합되면, 해당 콘텐츠는 http://kubernetes.io 에 공개된다. 게시된 콘텐츠의
품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
작동 방식은 다음과 같다.
풀 리퀘스트에 lgtm 과 approve 레이블이 있고, hold 레이블이 없고,
모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다.
쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의
자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 /hold 추가 또는
/lgtm 코멘트 보류).
모든 쿠버네티스 멤버는 코멘트에 /lgtm 을 추가해서 lgtm 레이블을 추가할 수 있다.
SIG Docs 승인자들만이 코멘트에 /approve 를
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
PR Wrangler 또는 SIG Docs 의장과
같은 특정 역할도 수행한다.
퀵윈(Quick Wins): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
메인 브랜치이외의 브랜치에 대한 PR: dev- 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. /assign @<meister's_github-username> 을 사용하여 문서 릴리스 관리자를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
랭글러를 위한 유용한 Prow 명령어
# 한글 레이블 추가
/language ko
# 둘 이상의 커밋인 경우 PR에 스쿼시 레이블 추가
/label tide/merge-method-squash
# Prow를 통해 PR 제목 변경(예: 진행 중인 작업(work-in-progress) [WIP] 또는 PR의 더 상세한 내용)
/retitle [WIP] <TITLE>
풀 리퀘스트를 종료하는 시기
리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다.
다음의 상황에서 PR을 닫는다.
작성자가 CLA에 2주 동안 서명하지 않았다.
작성자는 CLA에 서명한 후 PR을 다시 열 수 있다. 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다.
작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않았다.
풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다.
풀 리퀘스트를 닫으려면, PR에 /close 코멘트를 남긴다.
참고:fejta-bot이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다.
7.5 - 문서 스타일 개요
이 섹션의 주제는 문서 작성 스타일, 컨텐츠 형식과
구성, 쿠버네티스 문서화에 적합하게 사용자 정의된 Hugo 사용 방법에 대한
가이드를 제공한다.
개념 페이지는 쿠버네티스의 일부 측면을 설명한다. 예를 들어 개념 페이지는 쿠버네티스 디플로이먼트 오브젝트를 설명하고 배치, 확장 및 업데이트되는 동안 애플리케이션으로서 수행하는 역할을 설명할 수 있다. 일반적으로 개념 페이지는 일련의 단계가 포함되지 않지만 대신 태스크나 튜토리얼에 대한 링크를 제공한다. 개념 문서의 예로서 노드를 참조하자.
태스크
태스크 페이지는 단일 작업을 수행하는 방법을 보여준다. 아이디어는 독자가 페이지를 읽을 때 실제로 수행할 수 있는 일련의 단계를 제공하는 것이다. 태스크 페이지는 한 영역에 집중되어 있으면 짧거나 길 수 있다. 태스크 페이지에서 수행할 단계와 간단한 설명을 혼합하는 것은 괜찮지만, 긴 설명을 제공해야 하는 경우에는 개념 문서에서 수행해야 한다. 관련 태스크와 개념 문서는 서로 연결되어야 한다. 짧은 태스크 페이지의 예제는 저장소에 볼륨을 사용하도록 파드 구성을 참조하자. 더 긴 태스크 페이지의 예제는 활동성 및 준비성 프로브 구성을 참조하자.
튜토리얼
튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다.
새 페이지 작성
작성하는 각각의 새 페이지에 대해 콘텐츠 타입을
사용하자. 문서 사이트는 새 콘텐츠 페이지를 작성하기 위한 템플리트 또는
Hugo archetypes을
제공한다. 새로운 타입의 페이지를 작성하려면, 작성하려는 파일의 경로로 hugo new 를
실행한다. 예를 들면, 다음과 같다.
hugo new docs/concepts/my-first-concept.md
제목과 파일 이름 선택
검색 엔진에서 찾을 키워드가 있는 제목을 선택하자.
제목에 있는 단어를 하이픈으로 구분하여 사용하는 파일 이름을 만들자.
예를 들어
HTTP 프록시를 사용하여 쿠버네티스 API에 접근
이라는 제목의 문서는 http-proxy-access-api.md라는 이름의 파일을 가진다.
"쿠버네티스"가 이미 해당 주제의 URL에 있기 때문에 파일 이름에 "쿠버네티스" 를 넣을 필요가 없다.
예를 들면 다음과 같다.
문서에서 전문
에 title 필드를 입력하자.
전문은 페이지 상단의 3중 점선 사이에 있는
YAML 블록이다. 여기 예시가 있다.
---
title: HTTP 프록시를 사용하여 쿠버네티스 API에 접근
---
디렉터리 선택
페이지 타입에 따라 새로운 파일을 다음 중 하나의 하위 디렉터리에 넣자.
/content/en/docs/tasks/
/content/en/docs/tutorials/
/content/en/docs/concepts/
파일을 기존 하위 디렉터리에 넣거나 새 하위 디렉터리에
넣을 수 있다.
목차에 항목 배치
목차는 문서 소스의 디렉터리 구조를 사용하여
동적으로 작성된다. /content/en/docs/ 아래의 최상위 디렉터리는 최상위 레벨 탐색 기능을
생성하고, 하위 디렉터리는 각각 목차에 항목을
갖는다.
각 하위 디렉터리에는 _index.md 파일이 있으며 이는 해당 하위 디렉터리의 컨텐츠에 대한
"홈" 페이지를 나타낸다. _index.md에는 템플릿이 필요없다. 그것은
하위 디렉터리의 항목에 대한 개요 내용을 포함할 수 있다.
디렉터리의 다른 파일들은 기본적으로 알파벳순으로 정렬된다. 이것은 거의
최적의 순서가 아니다. 하위 디렉터리에서 항목의 상대적 정렬을 제어하려면
가중치: 전문의 키를 정수로 설정하자. 일반적으로 우리는
나중에 항목을 추가하기 위해 10의 배수를 사용한다. 예를 들어 가중치가
10인 항목은 가중치가 20인 항목보다 우선한다.
문서에 코드 포함
문서에 코드를 포함시키려면 마크다운 코드 블록 구문을 사용하여
파일에 코드를 직접 삽입하자. 다음 경우에
권장된다. (전체 목록은 아님)
이 코드는 kubectl get deploy mydeployment -o json | jq '.status'와 같은
명령어의 출력을 보여준다.
이 코드는 시도해보기에 적절하지 않다. 예를 들어
특정 FlexVolume 구현에 따라
파드를 만들기 위해 YAML 파일을
포함할 수 있다.
이 코드의 목적은 더 큰 파일의 일부를 강조하는 것이기 때문에
불완전한 예제다. 예를 들어 몇 가지 이유로
PodSecurityPolicy
를 사용자 정의 방법을 설명할 때 문서 파일에서 직접 짧은 요약 정보를 제공할 수 있다.
이 코드는 사용자가 다른 이유로 시도하기 위한 것이 아니다. 예를 들어
kubectl edit 명령을 사용하여 리소스에 새 속성을 추가하는 방법을
설명할 때 추가할 만한 속성을 포함하는
간단한 예를 제공할 수 있다.
다른 파일의 코드 포함
문서에 코드를 포함시키는 또 다른 방법은 새로운 완전한 샘플 파일
(또는 샘플 파일 그룹)을 만든 다음 문서의 샘플을 참조하는 것이다.
일반적이고 재사용 가능하며 독자가 스스로 실행해 볼 수 있도록 하는
샘플 YAML 파일을 포함시키려면 이 방법을 사용하자.
YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때
<LANG>/examples/ 의 하위 디렉터리 중 하나에 코드를 배치하자. 여기서 <LANG>은
주제에 관한 언어이다. 문서 파일에서 codenew 단축 코드(shortcode)를 사용하자.
{{< codenew file="<RELPATH>/my-example-yaml>" >}}
여기서 <RELPATH> 는 examples 디렉터리와 관련하여 포함될
파일의 경로이다. 다음 Hugo 단축 코드(shortcode)는 /content/en/examples/pods/storage/gce-volume.yaml
에 있는 YAML 파일을 참조한다.
참고:<LANG>/examples 디렉터리에 새 YAMl 파일을 추가할 때 파일이
<LANG>/examples_test.go 파일에도 포함되어 있는지 확인하자.
웹 사이트의 Travis CI 는 PR이 제출될 때 이 예제를 자동으로
실행하여 모든 예제가 테스트를 통과하도록 한다.
한 동안 쿠버네티스 문서에 기여한 후에,
스타일 가이드,
컨텐츠 가이드, 문서 작성에 사용되는 툴체인,
website 스타일, 풀 리퀘스트 리뷰와 병합
프로세스 또는 문서 작성의 다른 측면을 개선하기 위한 아이디어가 있을 수 있다. 투명성을 극대화하려면,
이러한 유형의 제안을 SIG Docs 회의나
kubernetes-sig-docs 메일링리스트에서 논의해야 한다.
또한, 현재의 작업 방식과 과거의 결정이 왜 획기적인 변경을
제안하기 전에 결정되었는지에 대한 맥락을 이해하는 데 실제로
도움이 될 수 있다. 현재의 문서 작업이 어떻게 진행되는지에 대한 질문의
답변을 얻는 가장 빠른 방법은 kubernetes.slack.com의
#sig-docs 슬랙 채널에 문의하는 것이다.
토론이 진행되고 원하는 결과에 SIG가 동의한
후에는, 제안한 변경 사항과 가장 적합한 방식으로
작업할 수 있다. 예를 들어, 스타일 가이드나 website의
기능을 업데이트하려면, sig-testing과 함께 작업이 필요할 수 있는
문서 테스트와 관련된 변경에 대해 풀 리퀘스트를 열어야 할 수 있다.
각 쿠버네티스 릴리스는 sig-release SIG(Special Interest Group)에 참여하는
사람들의 팀에 의해 조정된다. 특정 릴리스에 대한 릴리스 팀의 다른 구성원에는
전체 릴리스 리드와 sig-testing 및 기타 담당자가
포함된다. 쿠버네티스 릴리스 프로세스에 대한 자세한 내용은
https://github.com/kubernetes/sig-release를
참고한다.
특정 릴리스의 SIG Docs 담당자는 다음 작업을 조정한다.
문서에 영향을 미치는 새로운 기능이나 변경된 기능이 있는지 기능-추적 스프레드시트를
모니터링한다. 특정 기능에 대한 문서가 릴리스를 위해 준비가
되지 않은 경우, 해당 기능이 릴리스 되지 않을 수 있다.
sig-release 미팅에 정기적으로 참석하고 릴리스에 대한 문서의
상태를 업데이트한다.
기능 구현을 담당하는 SIG가 작성한 기능 문서를
리뷰하고 교정한다.
릴리스 관련 풀 리퀘스트를 병합하고 릴리스에 대한 Git 기능 브랜치를
유지 보수한다.
앞으로 이 역할을 수행하는 방법을 배우려는 다른 SIG Docs 기여자들을
멘토링한다. 이것을 "섀도잉"이라고 한다.
릴리스에 대한 산출물이 공개될 때 릴리스와 관련된 문서 변경
사항을 공개한다.
릴리스 조정은 일반적으로 3-4개월의 책임이며, SIG Docs 승인자
사이에서 의무가 순환된다.
새로운 기여자가 하나 이상의 쿠버네티스 리포지터리에 5개의
실질적인 풀 리퀘스트를 성공적으로 제출한 후에는
쿠버네티스 조직의 멤버십을
신청할 수 있다. 기여자의 멤버십은 이미 리뷰어인 두 명의 스폰서가
후원해야 한다.
새로운 문서 기여자는 쿠버네티스 슬랙 인스턴스의 #sig-docs
채널이나 SIG Docs 메일링리스트에서
스폰서를 요청할 수 있다.
신청자의 작업에 대해 확신이 있다면, 리뷰어는 신청자를 후원한다.
신청자가 멤버십 신청서를 제출할 때, 신청서에 "+1"로 코멘트를 남기고
신청자가 쿠버네티스 조직의 멤버십에
적합한 이유에 대한 세부 정보를 포함한다.
공동 의장의 역할은 서비스 중 하나이다. 공동 의장은 기여자 역량 확보, 프로세스와 정책 처리, 회의 예약과 진행, PR 랭글러 스케줄링, 쿠버네티스 커뮤니티의 문서에 대한 지지, 쿠버네티스 릴리스 주기에서 성공적으로 문서화되는지 확인하고, SIG Docs를 효과적인 우선순위에 놓이도록 집중한다.
다음과 같은 책임을 가진다.
SIG Docs가 우수한 문서화를 통해 개발자의 행복을 극대화하는 데 집중한다.
스스로가 커뮤니티 행동 강령을 준수하여 예를 보이고, SIG 멤버들이 지킬 수 있도록 책임을 진다.
기여에 대한 새로운 지침을 확인하여 SIG에 대한 모범 사례를 배우고 설정한다.
SIG 회의를 예약하고 진행한다. 주간 상태 업데이트, 브랜치별 회고/기획 세션과 필요에 따라 그 외 세션을 진행한다.
KubeCon 이벤트 및 기타 컨퍼런스에서 문서 스프린트를 스케줄링하고 진행한다.
CNCF와 플래티넘 파트너인 Google, Oracle, Azure, IBM 및 Huawei를 통해 SIG Docs를 대신하여 채용과 지지를 보낸다.
SIG를 원활하게 운영한다.
효과적인 회의 운영
효과적으로 회의를 예약하고 진행하기 위해, 이 지침은 수행할 작업, 수행 방법과 이유를 보여준다.
쿠버네티스 문서 한글화팀은 커뮤니티의
현지화 가이드에 따라 한글화를
위한 팀 마일스톤과 개발 브랜치를 관리한다. 본 섹션은 한글화팀의 팀 마일스톤 관리에 특화된
내용을 다룬다.
한글화팀은 master 브랜치에서 분기한 개발 브랜치를 사용한다. 개발 브랜치 이름은 다음과 같은
구조를 갖는다.
dev-<소스 버전>-ko.<팀 마일스톤>
개발 브랜치는 약 2주에서 3주 사이의 팀 마일스톤 기간 동안 공동의 작업을 위해 사용되며, 팀
마일스톤이 종료될 때 원 브랜치로 병합(merge)된다.
업스트림(upstream)의 릴리스 주기(약 3개월)에 따라 다음 버전으로 마일스톤을 변경하는 시점에는
일시적으로 release-<소스 버전> 브랜치를 원 브랜치로 사용하는 개발 브랜치를 추가로 운영한다.
한글화팀의 정기 화상 회의 일정과
팀 마일스톤 주기는 대체로 일치하며, 정기 회의를 통해 팀 마일스톤마다 PR 랭글러(wrangler)를
지정한다.
한글화팀의 PR 랭글러가 갖는 의무는 업스트림의
PR 랭글러가 갖는
의무와 유사하다. 단, 업스트림의 PR 랭글러와는 달리 승인자가 아니어도 팀 마일스톤의 PR 랭글러가
될 수 있다. 그래서, 보다 상위 권한이 필요한 업무가 발생한 경우, PR 랭글러는 해당 권한을 가진
한글화팀 멤버에게 처리를 요청한다.
참고: 단, 해당 원칙에는 예외가 있을 수 있으며, 이 경우에는 가능한
한글화 용어집을 준용한다.
참고: 기능 게이트는 쿠버네티스 버전에 따라 변경될 수 있으므로,
쿠버네티스 및 쿠버네티스 문서의 버전에 맞는 기능 게이트 목록을 적용하여 한글화를 진행한다.
한글화 용어집 정보
쿠버네티스 한글화 용어집은 한글화된 쿠버네티스 문서의 일관성을 위해서
각 영문 용어에 대한 한글화 방법을 제시한다.
한글화 용어집에 포함된 용어는 쿠버네티스 문서 한글화팀 회의를 통해 결정되었으며,
본 문서에 대한 ISSUE 및 PR을 통해서 개선한다.
한글화 용어집 개선 가이드
한글화 용어집의 개선(추가, 수정, 삭제 등)을 위한 과정은 다음과 같다.
컨트리뷰터가 개선이 필요한 용어을 파악하면, ISSUE를 생성하여 개선 필요성을 공유하거나 master 브랜치에
PR을 생성하여 개선된 용어를 제안한다.
개선 제안에 대한 논의는 ISSUE 및 PR을 통해서 이루어지며, 한글화팀 회의를 통해 확정한다.
리뷰어 및 승인자는 작업 중인 한글화 작업 브랜치(예: dev-1.17-ko.3)에 영향을 최소화 하기 위해서,
신규 한글화 작업 브랜치(예: dev-1.17-ko.4) 생성 시점에 맞춰 확정된 PR을 승인한다.
개선된 한글화 용어집은 신규 한글화 작업 브랜치부터 적용한다.
개선된 한글화 용어집에 따라 기존의 한글 문서에 대한 업데이트가 필요하며,
컨트리뷰션을 통해서 업데이트를 진행한다.
한글화 용어집
English
한글
비고
Access
접근
Active
Active
잡의 상태
Active Job
액티브 잡
Addons
애드온
admission controller
어드미션 컨트롤러
Age
기간
Allocation
할당량
alphanumeric
영숫자
Annotation
어노테이션
APIService
API서비스(APIService)
API 오브젝트인 경우
App
앱
Appendix
부록
Application
애플리케이션
Args
Args
약어의 형태이므로 한글화하지 않고 영문 표기
array
배열
autoscaler
오토스케일러
availability zone
가용성 영역(availability zone)
bare pod
베어(bare) 파드
beta
베타
Binding
바인딩(Binding)
API 오브젝트인 경우
boilerplate
상용구
Boot
부트
Build
빌드
Cache
캐시
Calico
캘리코(Calico)
canary
카나리(canary)
릴리스 방식에 관련한 용어인 경우에 한함
cascading
캐스케이딩(cascading)
CertificateSigningRequest
CertificateSigningRequest
API 오브젝트인 경우
character set
캐릭터 셋
Charts
차트
checkpoint
체크포인트
Cilium
실리움(Cilium)
CLI
CLI
Cluster
클러스터
ClusterRole
클러스터롤(ClusterRole)
API 오브젝트인 경우
ClusterRoleBinding
클러스터롤바인딩(ClusterRoleBinding)
API 오브젝트인 경우
Command Line Tool
커맨드라인 툴
ComponentStatus
컴포넌트스테이터스(ComponentStatus)
API 오브젝트인 경우
ConfigMap
컨피그맵(ConfigMap)
API 오브젝트인 경우
configuration
구성, 설정
Connection
연결
containerized
컨테이너화 된
Context
컨텍스트
Control Plane
컨트롤 플레인
controller
컨트롤러
ControllerRevision
컨트롤러리비전(ControllerRevision)
API 오브젝트인 경우
cron job
크론 잡
CronJob
크론잡(CronJob)
API 오브젝트인 경우
CSIDriver
CSI드라이버(CSIDriver)
API 오브젝트인 경우
CSINode
CSI노드(CSINode)
API 오브젝트인 경우
custom metrics
사용자 정의 메트릭
custom resource
사용자 정의 리소스
CustomResourceDefinition
커스텀리소스데피니션(CustomResourceDefinition)
API 오브젝트인 경우
Daemon
데몬
DaemonSet
데몬셋(DaemonSet)
API 오브젝트인 경우
Dashboard
대시보드
Data Plane
데이터 플레인
Deployment
디플로이먼트(Deployment)
API 오브젝트인 경우
deprecated
사용 중단(deprecated)
descriptor
디스크립터, 식별자
Desired number of pods
의도한 파드의 수
Desired State
의도한 상태
disruption
중단(disruption)
distros
배포판
Docker
도커
Dockerfile
Dockerfile
Docker Swarm
Docker Swarm
Downward API
다운워드(Downward) API
draining
드레이닝(draining)
egress
이그레스, 송신(egress)
endpoint
엔드포인트
EndpointSlice
엔드포인트슬라이스(EndpointSlice)
API 오브젝트인 경우
Endpoints
엔드포인트(Endpoints)
API 오브젝트인 경우
entry point
진입점
Event
이벤트(Event)
API 오브젝트인 경우
evict
축출하다
eviction
축출
Exec
Exec
expose
노출시키다
extension
익스텐션(extension)
Failed
Failed
파드의 상태에 한함
Federation
페더레이션
field
필드
Flannel
플란넬(Flannel)
form
형식
Google Compute Engine
Google Compute Engine
hash
해시
headless
헤드리스
health check
헬스 체크
Heapster
힙스터(Heapster)
Heartbeat
하트비트
Homebrew
Homebrew
hook
훅(hook)
Horizontal Pod Autoscaler
Horizontal Pod Autoscaler
예외적으로 API 오브젝트에 대해 외래어 표기법 적용하지 않고 원문 그대로 표기
hosted zone
호스팅 영역
hostname
호스트네임
Huge page
Huge page
Hypervisor
하이퍼바이저
idempotent
멱등성
Image
이미지
Image Pull Secrets
이미지 풀(Pull) 시크릿
Ingress
인그레스(Ingress)
API 오브젝트인 경우
IngressClass
인그레스클래스(IngressClass)
API 오브젝트인 경우
Init Container
초기화 컨테이너
Instance group
인스턴스 그룹
introspection
인트로스펙션(introspection)
Istio
이스티오(Istio)
Job
잡(Job)
API 오브젝트인 경우
kube-proxy
kube-proxy
Kubelet
Kubelet
Kubernetes
쿠버네티스
Kube-router
Kube-router
label
레이블
Lease
리스(Lease)
API 오브젝트인 경우
lifecycle
라이프사이클
LimitRange
리밋레인지(LimitRange)
API 오브젝트인 경우
limit
한도(limit)
리소스의 개수나 용량을 한정하기 위한 수치로 사용된 경우 선택적으로 사용 (API 오브젝트의 속성으로 limit을 사용한 경우는 가능한 영문 유지)
Linux
리눅스
load
부하
LocalSubjectAccessReview
로컬서브젝트액세스리뷰(LocalSubjectAccessReview)
API 오브젝트인 경우
Log
로그
loopback
루프백(loopback)
Lost
Lost
클레임의 상태에 한함
Machine
머신
manifest
매니페스트
Master
마스터
metadata
메타데이터
metric
메트릭
masquerading
마스커레이딩
Minikube
Minikube
Mirror pod
미러 파드(mirror pod)
monitoring
모니터링
multihomed
멀티홈드(multihomed)
MutatingWebhookConfiguration
MutatingWebhookConfiguration
API 오브젝트인 경우
naked pod
네이키드(naked) 파드
Namespace
네임스페이스(Namespace)
API 오브젝트인 경우
netfilter
넷필터(netfilter)
NetworkPolicy
네트워크폴리시(NetworkPolicy)
API 오브젝트인 경우
Node
노드(Node)
API 오브젝트인 경우
node lease
노드 리스(lease)
Object
오브젝트
Orchestrate
오케스트레이션하다
Output
출력
parameter
파라미터
patch
패치
Pending
Pending
파드, 클레임의 상태에 한함
PersistentVolume
퍼시스턴트볼륨(PersistentVolume)
API 오브젝트인 경우
PersistentVolumeClaim
퍼시스턴트볼륨클레임(PersistentVolumeClaim)
API 오브젝트인 경우
pipeline
파이프라인
placeholder pod
플레이스홀더(placeholder) 파드
Pod
파드
API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음
Pod Preset
파드 프리셋
PodAntiAffinity
파드안티어피니티(PodAntiAffinity)
PodDisruptionBudget
PodDisruptionBudget
API 오브젝트인 경우
PodSecurityPolicy
파드시큐리티폴리시(PodSecurityPolicy)
API 오브젝트인 경우
PodTemplate
파드템플릿(PodTemplate)
API 오브젝트인 경우
postfix
접미사
prefix
접두사
PriorityClass
프라이어리티클래스(PriorityClass)
API 오브젝트인 경우
Privileged
특권을 가진(privileged)
Prometheus
프로메테우스
proof of concept
개념 증명
Pull Request
풀 리퀘스트
Pull Secret Credentials
풀(Pull) 시크릿 자격증명
QoS Class
QoS 클래스
Quota
쿼터
readiness gate
준비성 게이트(readiness gate)
readiness probe
준비성 프로브(readiness probe)
Ready
Ready
Reclaim Policy
반환 정책
redirect
리다이렉트(redirect)
redirection
리다이렉션
Registry
레지스트리
Release
릴리스
ReplicaSet
레플리카셋(ReplicaSet)
API 오브젝트인 경우
replicas
레플리카
ReplicationController
레플리케이션컨트롤러(ReplicationController)
API 오브젝트인 경우
repository
리포지터리
request
요청(request)
리소스의 개수나 용량에 대한 요청 수치를 표현하기 위해 사용된 경우 선택적으로 사용 (API 오브젝트 속성으로 request를 사용한 경우는 가능한 영문을 유지)
resource
리소스
ResourceQuota
리소스쿼터(ResourceQuota)
API 오브젝트인 경우
return
반환하다
revision
리비전
Role
롤(Role)
API 오브젝트인 경우
RoleBinding
롤바인딩(RoleBinding)
API 오브젝트인 경우
rollback
롤백
rolling update
롤링 업데이트
rollout
롤아웃
Romana
로마나(Romana)
Running
Running
파드의 상태에 한함
runtime
런타임
RuntimeClass
런타임클래스(RuntimeClass)
API 오브젝트인 경우
Scale
스케일
Secret
시크릿(Secret)
API 오브젝트인 경우
segment
세그먼트
Selector
셀렉터
Self-healing
자가 치유
SelfSubjectAccessReview
셀프서브젝트액세스리뷰(SelfSubjectAccessReview)
API 오브젝트인 경우
SelfSubjectRulesReview
SelfSubjectRulesReview
API 오브젝트이지만 용어를 구성하는 단어 중 복수형 Rules를 '룰스'로 외래어 표기하는 경우 한국어 독자에게 다소 생경할 수 있어 예외적으로 영문 용어를 사용함
Service
서비스
API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음
ServiceAccount
서비스어카운트(ServiceAccount)
API 오브젝트인 경우
service discovery
서비스 디스커버리
service mesh
서비스 메시
Session
세션
Session Affinity
세션 어피니티(Affinity)
Setting
세팅
Shell
셸
Sign In
로그인
Sign Out
로그아웃
skew
차이(skew)
snippet
스니펫(snippet)
spec
명세, 스펙, 사양
specification
명세
StatefulSet
스테이트풀셋(StatefulSet)
API 오브젝트인 경우
stateless
스테이트리스
Static pod
스태틱(static) 파드
StorageClass
스토리지클래스(StorageClass)
API 오브젝트인 경우
SubjectAccessReview
서브젝트액세스리뷰(SubjectAccessReview)
API 오브젝트인 경우
Sub-Object
서브-오브젝트
support
지원
Surge
증가율
롤링업데이트 전략에 한함
System
시스템
taint
테인트(taint)
Task
태스크
Terminated
Terminated
파드의 상태에 한함
TokenReview
토큰리뷰(TokenReview)
API 오브젝트인 경우
tolerations
톨러레이션(toleration)
Topology spread constraints
토폴로지 분배 제약 조건
Tools
도구
traffic
트래픽
Type
타입
ubuntu
우분투
use case
유스케이스
userspace
유저스페이스(userspace)
Utilization
사용량, 사용률
ValidatingWebhookConfiguration
ValidatingWebhookConfiguration
API 오브젝트인 경우
verbosity
로그 상세 레벨(verbosity)
virtualization
가상화
Volume
볼륨
VolumeAttachment
볼륨어태치먼트(VolumeAttachment)
API 오브젝트인 경우
Waiting
Waiting
파드의 상태에 한함
Walkthrough
연습
Weave-net
위브넷(Weave Net)
Weaveworks 사의 솔루션 공식 명칭은 'Weave Net'이므로 한영병기 시 공식 명칭 사용
이 페이지에서는 
